Dependabot introduce un cooldown de 3 zile
GitHub a anunțat pe 23 iulie 2026 că Dependabot aplică implicit o perioadă de așteptare de cel puțin trei zile înainte să deschidă pull request-uri pentru actualizările obișnuite de versiune. Scopul este reducerea riscului ca un pachet nou compromis să intre automat în proiecte înainte ca ecosistemul să-l detecteze și să-l elimine.
Distincția esențială: schimbarea vizează doar „version updates”. Actualizările de securitate, create pentru remedierea unei vulnerabilități cunoscute, continuă să fie deschise imediat. Un cooldown pentru toate update-urile ar întârzia patch-uri tocmai când viteza contează.
Ce se schimbă concret
Pentru un release nou al unei dependențe fără o alertă de securitate asociată, Dependabot așteaptă implicit trei zile înainte să propună actualizarea. Fereastra poate oferi cercetătorilor, maintainerilor și registrelor timp să identifice și să retragă o versiune malițioasă.
Perioada poate fi configurată prin opțiunea „cooldown” din dependabot.yml. Echipele trebuie să-și verifice politica efectivă la nivel de repository și organizație, nu să presupună că același interval se potrivește fiecărui proiect.
De ce trei zile pot conta
Atacurile asupra lanțului de aprovizionare exploatează încrederea în procesul normal de actualizare. Dacă o versiune compromisă ajunge în registry și este preluată imediat de automatizări, organizația poate importa cod periculos înainte ca alerta publică să existe.
GitHub spune că Advisory Database a publicat peste 6.500 de alerte de malware npm în anul încheiat în mai 2026, față de aproximativ 6.200 în anul precedent. Compania argumentează că multe versiuni malițioase sunt descoperite și eliminate în primele ore, ceea ce face utilă o scurtă întârziere pentru update-urile neurgente.
Ce nu rezolvă cooldown-ul
Trei zile nu opresc o compromitere care rămâne nedetectată mai mult, sabotajul deliberat al unui maintainer sau un sistem de build compromis. Nici nu validează proveniența artefactului și nu dovedește că noul cod este sigur.
Cooldown-ul este un filtru temporal, nu un verdict de securitate. Valoarea lui apare într-un model de apărare în profunzime, alături de review, testare, controlul permisiunilor și monitorizarea vulnerabilităților.
O politică practică pentru echipele DevSecOps
- ▸Păstrează actualizările de securitate rapide și separă-le explicit de update-urile obișnuite de versiune.
- ▸Folosește lockfile-uri și verifică diferențele de dependențe tranzitive în pull request, nu doar versiunea directă.
- ▸Rulează instalările și testele CI cu token-uri limitate și fără secrete de producție disponibile joburilor neesențiale.
- ▸Dezactivează scripturile de instalare acolo unde ecosistemul și procesul de build permit acest lucru.
- ▸Cere review proporțional cu riscul pentru dependențele care ating autentificarea, datele, rețeaua sau pipeline-ul de livrare.
Implicații pentru România și UE
Pentru organizațiile europene, inclusiv cele vizate de NIS2, schimbarea este un exemplu de măsură tehnică utilă pentru gestionarea riscului din supply chain, nu o garanție automată de conformitate. Politica trebuie documentată, testată și adaptată la criticitatea serviciului.
Un proiect intern poate tolera trei zile pentru un update funcțional; un patch de securitate critic nu ar trebui ținut în aceeași coadă. Metrica utilă este timpul până la remediere pe tip de risc, nu simplul număr de pull request-uri închise.
Surse oficiale
Anunțul, distincția dintre tipurile de update și opțiunile de configurare sunt documentate de GitHub.
Prioritizează riscul, nu zgomotul
MONITOR AWARELY îți oferă contextul necesar pentru a separa vulnerabilitățile urgente de actualizările obișnuite ale dependențelor.