Co je CVE a co byste měli vědět
Srozumitelné vysvětlení CVE, CVSS skóre a jejich reálného dopadu na bezpečnost.
Každý týden přináší další titulky o “kritické zranitelnosti”. Další CVE. Další urgentní alert.
Po letech v application security jsem zblízka sledoval, jak se počty CVE zvyšují a tlak na týmy roste.
Diskuze se postupně posunula od porozumění zranitelnostem k pouhé reakci na ně.
V tomto článku si uděláme krok zpět. Co přesně je CVE? Jak jsme se dostali od několika tisíc ročně téměř k padesáti tisícům?
A co tento růst ve skutečnosti znamená?
Co je CVE?
CVE je zkratka pro Common Vulnerabilities and Exposures. Jsou to unikátní, standardizované identifikátory pro veřejně známé zranitelnosti ve veřejně vydaném softwaru. Smysl je jednoduchý: CVE ID slouží jako referenční metoda při komunikaci o konkrétní zranitelnosti.
Výhodou je, že veškerá další komunikace a koordinace může odkazovat na konkrétní číslo CVE, aby bylo jisté, že všechny strany mluví o stejné zranitelnosti. Díky tomu je jednodušší tyto problémy sledovat, opravovat nebo si o nich dohledat více informací ještě předtím, než je útočníci zneužijí.
Syntaxe CVE ID má jasný formát:
- Předpona CVE + ROK + libovolné číslice
- CVE-YYYY-NNNN (přípona NNNN se v daném kalendářním roce rozšiřuje dle potřeby)
Například:
Zpět do roku 1999
Společnost MITRE Corporation představila původní koncept toho, co dnes známe jako CVE List, v lednu 1999. Následně vznikla pracovní skupina, která vytvořila prvních 321 CVE záznamů. CVE List byl oficiálně spuštěn v září 1999.
Věděli jste, že úplně první CVE-1999-0001 byla Denial-of-Service (DoS) zranitelnost?
Během prvních 17 let, od roku 1999 do 2016, byl meziroční růst zhruba ~5 000 nových záznamů ročně. Ale v roce 2017 se vše změnilo.
V předchozích letech došlo k prvním velkým incidentům:
- CVE-2014-0160 (Heartbleed)
- CVE-2014-6271 (Shellshock)
Firmy začaly mnohem agresivněji auditovat své dependencies, bug bounty programy se rozšířily a bezpečnostní výzkumníci se výrazněji zaměřili na open-source software. Cloud platformy rychle expandovaly s nástupem Kubernetes a Docker.
Security tooling se rychle vyvíjel a integrace do CI/CD začaly odhalovat zranitelnosti ve velkém. Hromada dříve neviditelných chyb začala dostávat vlastní CVE ID.
MITRE Corporation rozšířila model CNA (CVE Numbering Authority). Dříve přiděloval většinu CVE centrálně přímo MITRE. CVE bývaly často sdružované (jedno CVE na vydání produktu) a mnoho menších problémů vůbec nedostalo své ID. Pak se ale stovky vendorů staly CNA a mohly přidělovat CVE svým produktům přímo.
Už samotná decentralizace dramaticky zvýšila objem. Jednotlivé bugy (včetně low-severity) začaly dostávat samostatná CVE. A výsledkem bylo, že v roce 2017 se počet publikovaných CVE více než zdvojnásobil.
Kdy je to kritické?
Úroveň závažnosti zranitelnosti popisuje její dopad a riziko. K hodnocení se typicky používá CVSS. Common Vulnerability Scoring System je otevřený framework pro hodnocení závažnosti bezpečnostních zranitelností v IT systémech. Skóre se počítá podle vzorce, který zhruba odhaduje obtížnost exploitace a její dopad. Výsledkem je číslo od 0 do 10, kde 10 znamená nejvyšší závažnost.
CVSS má více metrik i verzí a není úplně triviální se v něm zorientovat, to je ale na samostatný článek. Důležité je, že CVSS přijala velká část organizací jako primární způsob závažnosti zranitelností a je to standard i pro CVE.
| Závažnost | CVSS skóre |
|---|---|
| Žádná | 0.0 |
| Nízká | 0.1 - 3.9 |
| Střední | 4.0 - 6.9 |
| Vysoká | 7.0 - 8.9 |
| Kritická | 9.0 - 10.0 |
Počty Kritická jsou vyšší než kdykoli v historii. Roky 2024 a 2025 ukazují největší nárůsty v kritických CVE, jaké jsme kdy viděli.
Za posledních 5 let pozorujeme nový trend. Zatímco zranitelnosti střední závažnosti (Medium-severity) rostou nejrychleji, High (vysoké) a Critical (kritické) zranitelnosti rostou také v absolutních číslech. Tento trend naznačuje jak lepší detekci, tak rostoucí attack surface. Celkové riziko se tedy neustále zvyšuje.
Proč je tolik CVE?
Jsme v éře AI agentů a machine learningu a zároveň v době, kdy prudce roste množství softwaru a digitálních služeb. Bug bounty programy dospěly, bezpečnostních výzkumníků je víc než kdy dřív a tooling se zlepšil exponenciálně.
Security testing se navíc stává standardem napříč organizacemi, částečně i kvůli vyvíjejícím se zákonům a regulatorním požadavkům.
Jak se ekosystém rozšiřuje (cloud, API, SaaS, IoT), rozšiřuje se i attack surface a s ním se přirozeně zvyšuje celkový počet zranitelností.
Zvyšuje se riziko?
V pěti letech před rokem 2017 jsme viděli zhruba
~5k nových CVE ročně. V následujících pěti letech to bylo kolem
~20k nových CVE ročně.
A teď poslední 3 roky: růst kolem ~40k ročně, přičemž 2025 překonal absolutní rekord s ~48k novými CVE.
Celkově trvalo 19 let, než jsme překročili 100k CVE. 5 let na překročení 200k. A jen něco málo přes 2 roky na dosažení 300k+.
Objem zranitelností roste, protože roste digitální ekosystém. To, jestli roste i riziko, závisí na tom, jak dobře organizace řídí bezpečnost. Attack surface se však bezpochyby rozšiřuje.
Pokud v roce 2026 nemonitorujete CVE, dramaticky tím zvyšujete riziko pro svou organizaci.
Exploitace během dnů
Mindset “opravíme to příští kvartál” už nefunguje.
Bezpečnostní výzkumníci dnes o nálezech často mluví veřejně a exploitace může přijít během dnů (někdy i hodin).
Dříve byla typická osa:
CVE zveřejněno → analýza → dlouhé patch cykly v organizacích
Dnes častěji vidíme:
CVE zveřejněno → analýza → Proof of Concept → exploitace
With AI agents doing public patch diff analysis and automating the whole workflow efficiently.
A celé to ještě zrychlují AI agenti, kteří provádějí public patch diff analýzu a automatizují celý workflow velmi efektivně.
Co teď?
Tohle nejsou nové problémy. Nový je jejich rozsah a tempo, jakým rostou:
- problém objemu (desítky tisíc nových CVE ročně)
- problém prioritizace (ne všechny CVE mají stejný dopad)
- posun od „opravte všechno“ k inteligentní priorita úkolů
- potřeba dívat se na relevanci, exposure a exploitability
- postupný přechod k lepší viditelnosti, filtrování a kontextu
- alert fatigue v security týmech
Proto budujeme CVEalert, abychom pomohli menším organizacím vytvořit software katalog a nastartovat jejich vulnerability management.
CVEalert.io poskytuje přehled a sledování softwarových aktiv organizace a jejich CVE.
Nejde o to, zda CVE rostou. Klíčové je, jak se s tím růstem týmy naučí efektivně pracovat.
Jsme stále na začátku, ale jsme tu, abychom vám pomohli.
Reference: