24hodinová lhůta z CRA běží od 11. září a odpovědný je váš dependency graph

Od 11. září 2026 začnou být vymahatelné povinnosti reportovat zranitelnosti podle evropského Cyber Resilience Actu. Pokud máte na evropském trhu produkt s digitálními prvky, jste podle nařízení výrobce, ať už někdo z vašeho týmu článek 14 kdy četl, nebo ne. Číslo, které všichni citují, je 24 hodin, a to číslo je skutečné. Vyplatí se ale pochopit, co lhůtu spouští, protože to není 24 hodin od zveřejnění CVE. Je to 24 hodin od okamžiku, kdy zjistíte, že je ve vašem produktu aktivně zneužívaná zranitelnost. V tu chvíli musíte poslat úvodní varování jak příslušnému národnímu CSIRT, tak ENISA přes jednotnou reportovací platformu. Do 72 hodin následuje druhé, podrobnější hlášení a po zpřístupnění opravy nebo mitigace závěrečná zpráva. Co týmy nejčastěji zaskočí, je fakt, že „aktivně zneužívaná" zahrnuje i zneužití, které vidíte ve vlastní telemetrii. Takže když váš on-call inženýr uvidí v logu payload odpovídající známému deserialization gadgetu v knihovně, kterou jste nasadili, lhůta začala běžet, a je jí úplně jedno, že je pátek šest večer. Týká se to i starších produktů. Cokoliv, co jste uvedli na evropský trh a co stále dostává podporu, spadá do působnosti. Takže ten zákaznický portál, který jste postavili v roce 2021 a zapomněli na něj, je odpovědnost ležící na polici, tiše hromadící nezáplatované závislosti, zatímco se datum blíží.

Většina týmů, se kterými mluvíme, bere CRA jako něco, co spadá pod právní nebo compliance oddělení. To je zásadní omyl, který je kousne v přesně tu nejhorší chvíli. Právník vám do 24 hodin neřekne, jestli ta verze libwebp, kterou máte zabalenou přes tři vrstvy tranzitivních závislostí, je zrovna ta s heap overflow, protože ta odpověď žije ve vašem lockfilu, container images a build artefaktech, ne v nějakém policy dokumentu. Povinnost je právní, ale každý vstup potřebný k jejímu splnění je technický. Musíte na požádání vědět, co reálně běží v produkci, až po tranzitivní závislost a přesnou verzi, namapované na to, který produkt viditelný pro zákazníka je obsahuje. A tuhle odpověď musíte dostat dost rychle na to, abyste stihli sepsat hlášení před deadlinem. Pokud je vaším prvním krokem po reportu exploitu grepování Slack threadu z roku 2023 s dotazem, jestli si někdo pamatuje, která služba ten balík používá, už jste prohráli. Provedli jsme dost bezpečnostních auditů, abychom věděli, že mezera skoro nikdy není v samotné opravě. Je v čase stráveném zjišťováním, kde vlastně ten zranitelný kód žije. CRA z téhle latence dělá regulatorní riziko s reálnými pokutami, až 15 milionů eur nebo 2,5 procenta globálního obratu za vážná porušení.

Tahle část by vám měla být nepříjemná. AngularJS dosáhl konce životnosti na konci roku 2021 a pořád se objevuje v enterprise admin panelech všude možně. Vue 2 doběhlo na konci roku 2023 a opravdu velký kus SaaS světa nikdy nepřešel na Vue 3, protože přepis na composition API byl bolestivý a nikdo neměl rozpočet na UI, které „fungovalo dobře". Node.js 18 přestal být podporovaný v roce 2025, a pokud váš Dockerfile pořád říká FROM node:18-alpine, provozujete interpret, který už nikdy nedostane další bezpečnostní patch. Před CRA to byl běžný tech dluh, ten typ, co si poznamenáte na retru a odkládáte donekonečna. Teď je to jinak. Když se objeví zranitelnost v EOL balíku, žádná upstream oprava nepřijde, takže vaší jedinou compliant reakcí je buď už být dávno přemigrovaní, nebo aktivně udržovat fork, který si můžete sami záplatovat. O obojím se rozhoduje měsíce dopředu, ne v 24hodinovém okně po zneužití. EOL závislost v nasazeném produktu je odpovědnost, která se nabaluje, protože každé nové CVE proti ní je takové, které nevyřešíte zvednutím čísla verze. Nepříjemná pravda je, že migrace, kterou jste odkládali, se stala předpokladem pro compliance, zatímco jste se hádali, jestli za tu námahu vůbec stojí.

Nepotřebujete šesticifernou GRC platformu, abyste byli compliant. Potřebujete řízenou pipeline artefaktů, která produkuje reálný inventář, a jasnou cestu od „nahlášen exploit" k „sepsáno hlášení". Začněte generováním SBOM při každém buildu. Pokud jedete na Go nebo Node stacku, syft vygeneruje CycloneDX dokument v jednom kroku, a napojíte ho do CI tak, aby se žádný image nepushnul bez přiloženého SBOM jako OCI artefaktu. Díky tomu si pro jakýkoliv produkční tag stáhnete přesný seznam komponent, aniž byste cokoliv rebuildovali. Přidejte skenování přes grype nebo Trivy, které build failne na známě zneužívaných CVE, a hlavně mu podstrčte CISA KEV katalog, abyste dostávali signál právě na zranitelnosti, které se reálně zneužívají ve volné přírodě, protože přesně to je trigger, na kterém CRA záleží. SBOMy ukládejte někam, kde se dá dotazovat. My ty svoje pusheme do malé Postgres tabulky klíčované na digest image a produkt, takže když spadne CVE, on-call inženýr spustí jeden dotaz a za minutu dostane zpátky každou zasaženou službu i jejího ownera, místo odpoledne archeologie. Poslední kousek je runbook, který bere shodu s KEV jako incident s explicitní 24hodinovou lhůtou hned nahoře, s kontaktem na CSIRT a přihlašovacími údaji k ENISA platformě už zdokumentovanými, protože nejhorší chvíle na zjištění, že nemáte přístup do reportovacího portálu, je když už běží lhůta.

Šest týdnů není dost času udělat to pořádně, tak udělejte tu verzi, na které záleží. Zaprvé vygenerujte SBOM pro každý produkt, který máte na evropském trhu, včetně těch, na které dva roky nikdo nesáhl, a udělejte diff těch inventářů proti CISA KEV katalogu, abyste ještě dnes zjistili, jestli už náhodou nedodáváte něco zneužívaného. Tohle jedno cvičení obvykle odhalí aspoň jedno reálné překvapení na tým, se kterým jsme pracovali. Zadruhé identifikujte každou EOL závislost v tom inventáři a u každé udělejte poctivé rozhodnutí: migrovat teď, forknout a udržovat si to sami, nebo akceptovat zdokumentované riziko s plánem. „Nevěděli jsme" totiž od 11. září přestává být obhajitelná odpověď. Zatřetí napište runbook a reálně ho otestujte. Uspořádejte tabletop, kde někdo nasype falešný report exploitu do kanálu a vy naměříte, jak dlouho trvá vyprodukovat draft hlášení. Pokud je to číslo přes pár hodin, mezera je ve vašem toolingu, ne v lidech. Tenhle typ řízené pipeline dnes standardně stavíme do dodávek klientům, protože dodělávat to pod tlakem deadlinu je utrpení, a udělat to jednou pořádně znamená, že 24hodinová lhůta přestane být hrozbou a stane se dotazem, který už umíte spustit. Nařízení nikam nezmizí a datum je pevné. Dependency graph, který jste ignorovali, je to, co rozhodne, jestli ho stihnete.