Jak zvládnout rostoucí počty CVE s malým týmem

Co se změnilo: počty CVE

Níže uvedená čísla pocházejí přímo ze záznamů CVE Program a každý den se přepočítávají na naší stránce trendy zveřejňování CVE. Podle snímku pořízeného 12. 11. 2026 UTC:

• 47 801 CVE vyšlo v roce 2025, o 20 % více než v předchozím roce.
• 95 494 CVE vyšlo zatím v roce 2026, tedy 303 denně, o +131 % oproti dennímu tempu roku 2025.
• 155 denně má hodnocení High nebo Critical.
• 17 % všech záznamů od roku 2020 nemá skóre CVSS, ani od přidělovatele, ani z obohacení od CISA. Pokrytí se zlepšilo: v roce 2026 je tento podíl 6 %.
• Počet organizací, které tyto záznamy přidělily: 505. Na 20 největších z nich připadá 75 % záznamů.

• High nebo Critical
• Ostatní závažnosti a bez skóre

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

Denní průměr záznamů zveřejněných v každém roce; * označuje aktuální rok k dnešnímu dni. Zdroj: záznamy cvelistV5 CVE Program, snímek 12. 11. 2026 UTC. Filtry podle měsíce, závažnosti a přidělovatele: trendy zveřejňování CVE.

Nejde o jedno špatné čtvrtletí. Počet roste každý rok od roku 2020 a několik strukturálních změn zajišťuje, že poroste dál:

• Více přidělovatelů, kteří přidělují šířeji. Projekt linuxového jádra se stal CVE Numbering Authority v únoru 2024. Jeho zdokumentovaná politika je přidělit CVE každé opravě chyby, která by mohla být zranitelností, jakmile se oprava dostane do stabilního jádra, protože v okamžiku opravy často není jasné, zda je chyba zneužitelná. Samotná CNA jádra od té doby zveřejnila 18 221 CVE.
• Objevování s pomocí AI. V listopadu 2024 oznámily Project Zero od Googlu a DeepMind, že jejich agent Big Sleep našel v SQLite zneužitelnou chybu bezpečnosti paměti ještě předtím, než se dostala do vydání, což byl podle nich první veřejný příklad toho, že to AI agent dokázal v široce používaném softwaru. Takové nástroje zvyšují, kolik toho jeden výzkumník dokáže najít.
• NVD už nestíhá obohacovat všechno. NIST uvádí, že National Vulnerability Database od začátku roku 2024 nahromadila backlog neobohacených CVE a nedokázala ho odbavit, protože počty podání dál rostly. V dubnu 2026 přešla na model založený na riziku: CVE z katalogu Known Exploited Vulnerabilities od CISA a CVE ve federálním nebo kritickém softwaru se obohacují přednostně a zbytek je veden jako neplánovaný k okamžitému obohacení. Proces, který spoléhá na údaje o dotčených produktech z jedné databáze, teď čeká, nebo něco přehlédne.
• Méně času na reakci. Mandiant naměřil v letech 2018 a 2019 průměrnou dobu do zneužití 63 dní. Jeho zpráva M-Trends 2026 odhaduje pro rok 2025 minus sedm dní: zneužívání dnes běžně začíná dříve, než vyjde patch.
• Regulatorní lhůty. Podle Cyber Resilience Act EU výrobci hlásí aktivně zneužívanou zranitelnost včasným varováním do 24 hodin, oznámením do 72 hodin a závěrečnou zprávou do 14 dnů od zpřístupnění opravy (co CRA požaduje). Lhůta je stejná pro tým tří lidí jako pro tým tří set.

Nic z toho neznamená, že software je méně bezpečný. Znamená to, že počet věcí, na které se tým musí podívat, každý rok roste, zatímco tým ne.

Co se v procesu malého týmu rozbije

Rostoucí počty nerozbíjejí správu zranitelností proto, že je víc zranitelností k opravě. Rozbíjejí ji proto, že se každý ruční krok opakuje u každého CVE.

Ruční krok	Proč při dnešním objemu selhává
Ruční sestavování inventáře	Tabulka nebo SBOM vytvořená před auditem je zastaralá den po dalším vydání.
Čtení feedu	Při 155 záznamech High nebo Critical denně to nikdo nestíhá.
Dotaz na vývoj „používáme X?“	Stejná otázka u každého CVE, pořád týmž vytíženým lidem. Úzkým hrdlem je samotná otázka.
Jeden tiket na CVE a repozitář	Z CVE ve sdílené knihovně se stanou desítky duplicitních tiketů, které zahltí backlog.
Odpovídání každému zákazníkovi zvlášť	Dotazy rostou s počtem zákazníků, ne s počtem zranitelností.
Dokumenty v PDF nebo na wiki	Nástroje zákazníků nedokážou PDF porovnat se svým inventářem, takže se každý čtenář ptá znovu.
Lhůty, které se neposouvají	Doba do zneužití se zkracuje, zatímco ruční proces se s rostoucím objemem zpomaluje.

Inventář. Většina týmů, které vedou seznam komponent ručně, ho aktualizuje před auditem nebo dotazníkem od zákazníka. Mezi těmito daty popisuje software, který se už nedodává. Každá otázka ohledně CVE pak začíná rekonstrukcí toho, co vydání obsahovalo.

Feed. Čtením bezpečnostních upozornění týmy začínají a je to první krok, který se zhroutí. Slýcháme od týmů, které to stále dělají ručně, včetně jednoho, kde skenování zranitelností znamená, že lidé čtou fóra o CVE. Funguje to, dokud to jednoho dne nepřestane fungovat, a na ten den neupozorní žádný signál.

Otázka na vývoj. „Používáme tuto knihovnu a v jaké verzi?“ vyruší vývojáře u každého CVE, které by se mohlo týkat. Jeden dvoučlenný tým produktové bezpečnosti nám řekl, že jeho práce je mačkání tlačítek jen proto, aby stíhal, a na zlepšování procesu nezbývá čas.

Tikety. Když má sdílená knihovna CVE a každý repozitář si otevře vlastní tiket, backlog počítá stejné rozhodnutí mnohokrát. Týmy se naučí backlog ignorovat a pak přehlédnou tiket, na kterém záleželo.

Odpovědi zákazníkům. Po široce medializované zranitelnosti nebo útoku na dodavatelský řetězec se zákazníci ptají: „Jsme zasaženi?“ Odpovídat každému zvlášť stojí nejvíc času právě v den, kdy ho je nejméně.

Dokumenty. Prohlášení v PDF nebo stránku na wiki musí na straně zákazníka přečíst člověk. Skenery zákazníků a stále častěji i regulátoři očekávají SBOM, VEX a bezpečnostní upozornění ve formátech, které dokáže spárovat stroj.

Lhůty. Včasné varování splatné do 24 hodin nebo exploit, který se objeví dřív než patch, nečeká, až se fronta vyprázdní.

Co automatizovat a v jakém pořadí

Každý krok ubírá práci dalšímu, takže na pořadí záleží víc než na volbě nástrojů.

1. Vězte, co dodáváte. SBOM z každého buildu promění otázku „jsme zasaženi?“ ve vyhledání.
2. Párujte průběžně a s více zdroji. Nová CVE se kontrolují proti každé uložené SBOM, takže feed nikdo nečte.
3. Omezte šum. Nálezy pro věci, které nedodáváte, a duplicity se k člověku vůbec nedostanou.
4. Provádějte triáž poloautomaticky. Fakta se doplní sama; rozhodnutí dělá člověk.
5. Dělejte vše strojově čitelné. Každé rozhodnutí se udělá jednou a znovu ho využije každý čtenář.
6. Odpovězte jednou a veřejně. Dotaz, který nikdy nepřijde, nestojí nic.

1. Generujte SBOM pro každý build automaticky

Co nahrazuje: tabulku a otázku na vývoj. SBOM generovaná během buildu popisuje, co build skutečně použil, a když si jednu uchováte pro každou dodanou verzi, můžete odpovědět za loňské vydání stejně jako za main. Zákazníci provozují staré verze; váš inventář je musí pokrýt.

Minimální verze: SBOM generovaná v CI pro každý build vydání, uložená vedle artefaktu vydání. Lepší: SBOM zaznamenaná přímo z buildu, ne dodatečně odvozená z lockfilů, takže obsahuje i komponenty stažené mimo správce balíčků (SBOM z doby buildu, automatizace SBOM).

Náklady: den nebo dva práce na pipeline pro minimální verzi, pak nic za každé vydání. Signál, že to funguje: u kteréhokoli vydání dokážete vypsat jeho komponenty, aniž byste se kohokoli ptali.

2. Párujte průběžně s několika zdroji zranitelností

Co nahrazuje: čtení feedu. Párování je práce pro stroj: každé nové CVE proti každé uložené SBOM, ne jen proti SBOM buildu, který právě proběhl. Staré vydání, které bylo při dodání čisté, je zasaženo v den, kdy vyjde CVE pro některou z jeho komponent.

Jeden zdroj nestačí. Kvůli backlogu obohacování v NVD mohou údaje o dotčených produktech přijít pozdě, nebo vůbec. Bezpečnostní upozornění ekosystémů, jako GitHub Advisory Database a OSV, bývají rychlejší a říkají, které verze balíčků jsou dotčené, v pojmech daného ekosystému. EU Vulnerability Database od ENISA přidává kontext EU.

Minimální verze: plánovaný job, který každý den znovu prověří každou uloženou SBOM proti agregovanému zdroji a nahlásí nové shody. Signál, že to funguje: o tom, že je vydání zasaženo, se dozvíte dřív, než vám to řekne zákazník. Jak to vypadá v CRACI, ukazuje sledování zranitelností.

3. Omezte šum dřív, než se na něj kdokoli podívá

Co nahrazuje: ruční kontrolu nálezů, na kterých nezáleží. Většina šumu vzniká už na začátku: inventáři, které uvádějí věci, které nedodáváte, několika nástroji hlásícími stejné CVE a závislostmi, které nikdo nepotřebuje. Opravte inventář, počítejte každý nález jen jednou podle package URL (PURL), verze a CVE, dodávejte méně závislostí a pak přidejte kontext zneužitelnosti z CISA KEV, EPSS a VEX. Stránka Jak omezit šum zranitelností tyto páky prochází jednu po druhé. Signál, že to funguje: nálezů na dodané vydání ubývá a důvody jsou zaznamenané.

4. Provádějte triáž poloautomaticky

Co nahrazuje: člověka, který ke každému nálezu shromažďuje fakta. Rozdělte práci přesně:

• Automaticky: závažnost, zda je známo, že se zneužívá, které produkty a verze obsahují komponentu, vlastnický tým, navržená priorita a termín.
• Člověk: rozhodnutí. Opravit, zmírnit, přijmout s datem vypršení, nebo označit jako nedotčené se zdůvodněním.

Co není bezpečné automatizovat: uzavření nálezu jako nedotčeného bez zaznamenaného důvodu. To je potlačení a vrátí se vám při auditu nebo incidentu. Pravidla pro řazení popisuje stránka určování priorit zranitelností.

Minimální verze: 15 minut denně nad frontou, která je už seřazená a vyplněná. Signál, že to funguje: každé rozhodnutí má zaznamenaný důvod a nic nečeká, až někdo něco dohledá.

5. Dělejte vše strojově čitelné

Co nahrazuje: PDF, stránky na wiki a e-maily, které musí přečíst člověk. Zveřejňujte SBOM ve formátu CycloneDX nebo SPDX (CycloneDX vs SPDX), rozhodnutí o nedotčenosti jako VEX a bezpečnostní upozornění v CSAF. Skenery zákazníků a regulátoři je pak mohou zpracovat bez člověka, takže každé rozhodnutí se udělá jednou a znovu ho využije každý, kdo se zeptá.

Minimální verze pro malý tým: SBOM a VEX na vyžádání ze stálého umístění; CSAF, až o něj zákazníci začnou žádat. Signál, že to funguje: nástroje zákazníků přestanou označovat to, na co jste už odpověděli.

6. Odpovězte jednou a veřejně

Co nahrazuje: jedno e-mailové vlákno na zákazníka. Ke každému významnému CVE zveřejněte bezpečnostní upozornění nebo stavovou stránku s dotčenými a opravenými verzemi a mějte šablonu odpovědi, která na ni odkazuje. Průvodce odpovědí na otázku „týká se nás toto CVE?“ ukazuje, jak odpověď zjistit, a článek jak odpovídat zákazníkům po útoku na dodavatelský řetězec obsahuje šablony odpovědí. Nejlevnější dotaz je ten, který nikdy nepřijde. Signál, že to funguje: na většinu dotazů odpovíte odkazem.

Pak opravujte

Automatické pull requesty s aktualizacemi závislostí udržují rutinní práci v pohybu; seskupujte je po týdnech nebo po vydáních, aby review zůstalo zvládnutelné. Aktualizace jednoho upstreamového balíčku často odstraní několik zranitelných tranzitivních závislostí najednou a je levnější než patchovat každou zvlášť (automatizovaná náprava zranitelností). Pak pomocí policy gates, které zablokují build, zabraňte tomu, aby se nové známé škodlivé komponenty vracely.

Plán podle velikosti týmu

Hodiny jsou ilustrační odhady pro plánování, ne benchmarky.

	Jeden člověk na částečný úvazek	Bezpečnostní nebo PSIRT funkce o 2 až 5 lidech	Větší tým
Automatizujte nejdřív	Kroky 1 a 2: SBOM pro každý build a průběžné párování	Kroky 1 až 3, pak směrování na vlastníky v kroku 4	Všech šest, s policy gates v každé pipeline
Zůstává ruční	Rozhodnutí u každého nálezu High nebo Critical; odpovědi zákazníkům podle šablony	Rozhodnutí, zdůvodnění VEX, bezpečnostní upozornění k významným CVE	Rozhodnutí, výjimky a samotný proces
Týdenní čas, ilustrační	2 až 4 hodiny	4 až 8 hodin na osobu	Určuje ho objem rozhodnutí, ne feed

Pokud už provozujete PSIRT, platí stejné pořadí; úplný model procesu popisuje životní cyklus správy zranitelností a škálování týmu PSIRT se věnuje dotazům zákazníků, kterých s každým CVE přibývá.

Jak poznat, že to funguje

• Doba od zveřejnění CVE po „dotčeno“ nebo „nedotčeno“, pro každý produkt.
• Podíl dotazů zákazníků zodpovězených ze zveřejněných materiálů.
• Nálezy na dodané vydání, ne na sken.
• Podíl rozhodnutí se zaznamenaným důvodem.
• Hodiny týdně strávené prací se zranitelnostmi a zda ubývají.

Nejdřív si změřte vlastní výchozí stav. Spolehlivé oborové benchmarky pro tyto metriky neexistují a žádné neuvádíme.

Najmout, koupit, nebo změnit proces?

• Najměte, když jde o opravování zranitelností ve vlastním kódu nebo o bezpečnostní práci směrem k zákazníkům, která vyžaduje úsudek.
• Kupte nástroje pro kroky, které se opakují u každého CVE: kroky 1, 2, 3 a 5.
• Změňte proces u vlastnictví a lhůt: kdo rozhoduje a do kdy.

U toho posledního buďte upřímní. Nástroj bez vlastníka vytvoří dashboard, který nikdo nečte.

Kam zapadá CRACI

CRACI automatizuje kroky 1 a 2 a části kroků 3 a 4 u softwaru sestavovaného v GitHub Actions. Nahrazuje vaše runnery hostované na GitHubu a během běhu každého jobu zaznamenává balíčky, které job skutečně stáhl, včetně balíčků obnovených z cache CI a skrytých závislostí, které neuvádí žádný lockfile.

• SBOM z každého buildu. SBOM každého jobu identifikuje každou komponentu pomocí PURL a nese stav úplnosti, takže víte, kdy něco nebylo vidět. Historie buildů uchovává každý dřívější build s jeho SBOM, takže vidíte, které buildy obsahovaly zranitelnou závislost, přímou nebo tranzitivní.
• Průběžné párování. Monitorované SBOM se průběžně znovu vyhodnocují a nálezy se agregují napříč buildy a repozitáři, takže CVE ve sdílené knihovně se ukáže jako jeden problém, ne čtyřicet.
• Upozornění a brány. CRACI upozorní příslušné lidi na zranitelnost a její závažnost a policy gates mohou build zastavit v reálném čase, včetně buildu, který obsahuje konkrétní CVE.
• Triáž a směrování. Bezpečnostní týmy provádějí triáž nálezů v CRACI a každý z nich předají týmu, který vlastní opravu.
• Strojově čitelné SBOM. SBOM se exportují jako CycloneDX nebo SPDX a CRACI podporuje VEX.

CRACI nezveřejňuje bezpečnostní upozornění, nenabízí analýzu dosažitelnosti a neskenuje váš vlastní kód. Účtuje jen minuty buildu: $0.002 za vCPU-minutu ($0.004 za výchozí runner se 2 vCPU), účtováno po sekundách, bez měsíčního poplatku, bez poplatku za SBOM a v tuto chvíli bez licenčního poplatku. Viz ceník.

Automatizujte první dva kroky ještě dnes: spouštějte své buildy na CRACI. Před obecnou dostupností zavádíme každý tým osobně.

Kdy CRACI není řešením

• Váš software se nesestavuje v GitHub Actions. GitLab CI a Jenkins jsou v plánu vývoje.
• Vaše expozice je hlavně infrastrukturní: servery, koncová zařízení a konfigurace cloudu. Lépe se hodí nástroje pro správu zranitelností infrastruktury.
• Integrujete firmware třetích stran, který nesestavujete. Lépe se hodí nástroje pro analýzu binárek.
• Váš backlog tvoří hlavně skutečné, zneužitelné nálezy ve vlastním kódu. To je problém kapacity pro nápravu, ne problém automatizace.

Automatizace správy zranitelností: časté dotazy

Proč je dnes CVE o tolik víc?

CVE přiděluje víc organizací a některé je přidělují šířeji: linuxové jádro se v roce 2024 stalo CVE Numbering Authority a přiděluje CVE každé opravě chyby, která by mohla být zranitelností. Nástroje s pomocí AI najdou víc chyb na jednoho výzkumníka. V roce 2025 vyšlo 47 801 CVE a rok 2026 běží tempem 303 denně. Tento trend trvá už roky.

Jak může malý tým stíhat nová CVE?

Tím, že je nečte. Generujte SBOM pro každý build, nová CVE automaticky párujte s každou uloženou SBOM, omezte šum a lidem nechte jen rozhodnutí o tom, co zbude. Malý tým stíhá díky odstranění kroků, které se opakují u každého CVE, ne díky rychlejší práci.

Co ve správě zranitelností automatizovat jako první?

Inventář: SBOM generovanou v CI pro každý build vydání, uloženou s vydáním. Závisí na ní každý další krok a otázku „jsme zasaženi?“ mění z dotazu na vývoj ve vyhledání. Průběžné párování s těmito SBOM přichází na řadu jako druhé.

Potřebujeme na řešení zranitelností bezpečnostní tým?

Na začátek ne. Jeden člověk, který proces vlastní na částečný úvazek, ho zvládne, pokud jsou inventář, párování a omezení šumu automatizované. Víc než tým potřebujete jmenovaného vlastníka a lhůty. Najímejte, až se práce stane opravováním vlastního kódu nebo bezpečnostní prací směrem k zákazníkům.

Jak zjistíme, která nová CVE se týkají našeho produktu?

Uchovávejte SBOM pro každou dodanou verzi a všechny je znovu zkontrolujte, kdykoli vyjdou nová CVE, a to proti více než jednomu zdroji zranitelností. CVE se vás týká, když odpovídá komponentě a verzi, kterou skutečně dodáváte. Kontext zneužitelnosti a VEX pak řeknou, zda na tom záleží.

Co znamená „strojově čitelné“ u SBOM, VEX a bezpečnostních upozornění a proč na tom záleží?

Znamená to standardní strukturovaný formát, který dokáže zpracovat nástroj: CycloneDX nebo SPDX pro SBOM, VEX pro prohlášení o nedotčenosti, CSAF pro bezpečnostní upozornění. Skener zákazníka je dokáže spárovat se svým inventářem, aniž by je kdo četl, takže rozhodnutí, které uděláte jednou, znovu využije každý zákazník i nástroj.

Jak velkou část triáže lze bezpečně automatizovat?

Shromažďování faktů: závažnost, stav zneužívání, které produkty a verze obsahují komponentu, vlastníka, navrženou prioritu a termín. Samotné rozhodnutí by mělo zůstat na člověku. Nikdy automaticky neuzavírejte nález jako nedotčený bez zaznamenaného důvodu.

Kolik máme času na reakci na kritické CVE?

Méně, než většina procesů předpokládá. M-Trends 2026 od Mandiantu odhaduje průměrnou dobu do zneužití v roce 2025 na minus sedm dní, tedy zneužití dřív, než existuje patch. Podle Cyber Resilience Act EU vyžaduje aktivně zneužívaná zranitelnost včasné varování do 24 hodin. Stanovte si vlastní lhůtu podle závažnosti a zneužívání a měřte se podle ní.