Dependabot čeká tři dny, než nabídne novou verzi. Bezpečnostních oprav se to netýká

Nástroj, který otevře žádost o sloučení hned, jak vyjde nová verze knihovny, dělá útočníkovi službu. Napadené vydání někdo obvykle odhalí během hodin, jenže to je pořád dost času na to, aby se stihlo dostat do cizích projektů. GitHub proto oznámil 23. července 2026, že jeho Dependabot napříště tři dny počká, než novou verzi nabídne.

Dvě různé práce jednoho nástroje

Dependabot dělá dvě věci, které se snadno pletou. Bezpečnostní aktualizace reaguje na vydaný záznam o zranitelnosti: přijde upozornění a s ním žádost o sloučení, která projekt posune na opravenou verzi. Aktualizace verzí naproti tomu jen drží závislosti aktuální bez ohledu na to, jestli je se stávající verzí něco v nepořádku.

Čekání platí výhradně na to druhé. Dokumentace to popisuje jako výchozí chování: tři dny se uplatní, i když volbu cooldown nikdo v souboru dependabot.yml nenastavil, a na bezpečnostní aktualizace se nevztahují. GitHub to zdůvodňuje tím, že by šlo o zdržení opravy vady, která je už veřejná.

Samotná volba nová není. Podle přehledu, který v březnu 2026 sepsal Andrew Nesbitt, dostal Dependabot blok cooldown už v červenci 2025. Změna je v tom, že se čekání nově uplatní i u projektů, které si o ně neřekly.

Případ, na kterém to GitHub vysvětluje

V září 2025 vylákal útočník podvodným e-mailem přihlašovací údaje jednoho správce v registru npm a vydal upravené verze balíčků chalk, debug a zhruba tuctu dalších. Dohromady mají přes dvě miliardy stažení týdně. Vložený kód přepisoval v prohlížeči adresy kryptoměnových peněženek.

Jak dlouho byly ty verze v registru, se v pramenech liší. GitHub píše o zhruba dvou hodinách, bezpečnostní inženýr William Woodruff uvádí ve svém rozboru u balíčku chalk „méně než dvanáct hodin“. Ani jeden z nich neuvádí, od čeho a po co přesně měří, takže rozdíl rozhodnout nejde. Na tom podstatném to nic nemění: automatický nástroj se do takového okna vejde i v té kratší podobě.

Kolik dní je dost

Tady se GitHub rozchází s lidmi, od kterých ten nápad pochází. Woodruff sestavil tabulku deseti známých případů a u každého odhadl, jak dlouho byla napadená verze dostupná. Osm z deseti mělo okno kratší než týden, takže sedmidenní čekání by podle něj většinu z nich zastavilo, čtrnáctidenní všechny kromě jediného. Tím jediným je xz-utils s oknem asi pět týdnů.

Táž tabulka ale ukazuje i případy, na které tři dny nestačí nebo je stačí jen tak tak: útok na tj-actions v ní má okno tři dny a napadený Kong Ingress Controller zhruba deset. GitHub svoji hranici obhajuje jinou sadou dat, totiž přehledem 21 široce popsaných útoků z let 2018 až 2026, a odůvodňuje ji tím, že tři dny jsou kompromis: dost na většinu útoků, ne tak dlouho, aby závislosti zbytečně zastarávaly.

Ostatní nástroje se rozhodly různě. Nesbitt uvádí, že Snyk má napevno zabudovaných 21 dní bez možnosti nastavení, kdežto Mend v Renovate 42 udělal tři dny výchozí hodnotou pro balíčky npm ve svém doporučeném nastavení. Samotný Renovate tuhle vlastnost zná léta pod jménem minimumReleaseAge, dřív stabilityDays, a jako příklad v dokumentaci uvádí čtrnáct dní.

Osmnáct nových škodlivých balíčků npm denně

Proč se tím vůbec někdo zabývá, ukazují čísla z databáze bezpečnostních hlášení, kterou GitHub vede. Za rok končící květnem 2026 v ní přibylo přes 6 500 hlášení o škodlivém kódu v npm, o rok dřív jich bylo kolem 6 200. To je zhruba osmnáct nově zachycených balíčků každý den.

Proti čemu čekání nepomůže

GitHub v oznámení sám vypisuje, co tímhle opatřením neošetří: zadní vrátka, která útočník do vydání vloží a nechá spát, sabotáž samotného správce projektu a napadený systém pro sestavení balíčku. Právě sem patří xz-utils, jehož okno Woodruff odhaduje na pět týdnů; na tak dlouhou lhůtu nedosáhne ani Snyk se svými jednadvaceti dny. Čekání je stavěné na jeden konkrétní vzorec, kdy se napadená verze vydá, rychle rozšíří a rychle odhalí.

Jako doplněk GitHub jmenuje připínání verzí zámkovým souborem, vypnutí instalačních skriptů v prostředí pro sestavení, omezení oprávnění přístupových tokenů a čtení změn před sloučením.

Jak si to nastavit jinak

Kdo chce jinou lhůtu, nastaví ji v bloku cooldown. Položka default-days platí pro závislosti bez vlastního pravidla; u správců balíčků, kteří rozlišují úrovně sémantického verzování, jdou zvlášť nastavit semver-major-days, semver-minor-days a semver-patch-days. Seznamy include a exclude pojmou po 150 položkách a přijímají hvězdičku jako zástupný znak; když je balíček v obou, vyhrává exclude a aktualizuje se hned.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 7
      exclude:
        - "@nase-firma/*"

Seznam podporovaných správců balíčků je v dokumentaci dlouhý a sahá od Bundleru a Carga přes Gradle, Maven a NuGet až po Terraform a vcpkg. Rozlišování podle úrovně sémantického verzování ale nemají všichni.

Zbytek ekosystému to má taky

Dependabot je jen jedno místo, kde se čekání dá zapnout, a podle Nesbittova přehledu ne to první. V JavaScriptu přišel pnpm s volbou minimumReleaseAge v září 2025, Yarn týž měsíc pod jménem npmMinimalAgeGate, Bun v říjnu 2025 a samotné npm v únoru 2026 jako min-release-age. V Pythonu má uv přepínač --exclude-newer, pip od verze 26 --uploaded-prior-to, Poetry vlastní obdobu. Ruby dostalo čekání v Bundleru 4.0.13 začátkem června 2026.

Nesbitt k tomu dodává, že u distribucí jako Debian nebo Fedora by totéž opatření stálo víc, než by přineslo, protože mezi vydáním knihovny a jejím rozšířením u nich stojí člověk, který balíček prohlédne a přebalí. V registrech typu npm nebo PyPI je vydání a rozeslání jeden a týž úkon. Čekání na aktualizaci tedy těmhle ekosystémům dodatečně vyrábí něco na způsob prodlevy, kterou nikdy neměly.