Tendenser i offentliggørelse af CVE'er

47.802 CVE-poster blev offentliggjort i 2025, en stigning på 20 % i forhold til året før. 2026 har allerede nået 88.746, og der er stadig måneder tilbage.

Mængden er vokset hvert år, siden CVE-programmet begyndte, men væksttakten ændrede sig markant i 2026. Brug grafen ovenfor til at se tendensen pr. måned, kvartal eller år.

På denne side. Grafen og tallene ovenfor er CVE-statistikker, der genopbygges dagligt fra CVE-programmets cvelistV5-repository, samme kilde som CVE-programmet offentliggør fra.

De dækker offentliggjort mængde efter CVSS-alvorlighed, efter tildelende organisation og pr. uge, måned, kvartal eller år samt de seneste kritiske poster. Detaljer om en enkelt sårbarhed finder du ved at følge et ID til cve.org.

Tre ting sker på samme tid, og de offentliggjorte poster kan ikke skille dem ad.

Flere organisationer kan nu tildele CVE-ID'er, så sårbarheder, der tidligere aldrig blev registreret, bliver registreret. Automatiseret og AI-assisteret sårbarhedsopdagelse har øget, hvor meget én forsker kan finde. Og CISA's berigelsesprogram har efterfyldt detaljer i ældre poster, hvilket ændrer historiske tal bagud i tid.

Stigende CVE-tal er derfor ikke i sig selv bevis for, at software bliver mindre sikker.

En CNA er en organisation med tilladelse til at tildele CVE-ID'er og offentliggøre poster inden for sit eget område, som regel sine egne produkter. 497 CNA'er optræder i dette datasæt.

Leverandører, open source-projekter, bug bounty-platforme og nationale CERT'er fungerer alle som CNA'er. Den største her er mitre med 39.586 poster. Fordi én CNA, der ændrer sin proces, mærkbart kan flytte totalerne, lader grafen dig filtrere på én organisation ad gangen.

CVSS scorer en sårbarhed fra 0,0 til 10,0 og inddeler den i bånd: Lav (0,1-3,9), Middel (4,0-6,9), Høj (7,0-8,9) og Kritisk (9,0-10,0).

Scoren beskriver iboende tekniske egenskaber, for eksempel hvordan sårbarheden nås, og hvad den kompromitterer. Den er ikke et mål for, hvor stor risiko en bestemt organisation løber.

18.0% af de poster, der er offentliggjort siden 2020, har ingen CVSS-score i hverken CNA'ens egne data eller CISA's berigelse.

Scoring var ikke påkrævet i det meste af CVE-programmets historie. Dækningen forbedres kraftigt fra 2023 og frem og er nu næsten fuldstændig, så når båndet Ukendt skrumper i grafen, afspejler det en ændring i rapporteringspraksis, ikke en ændring i selve sårbarhederne. En analyse, der ignorerer poster uden score, vil undervurdere ældre år.

En sårbarhed er en fejl i software. En CVE er et offentligt ID, der tildeles et bestemt, offentliggjort tilfælde af en sådan fejl.

De fleste sårbarheder får aldrig en CVE: De findes og rettes internt, eller de falder uden for alle CNA'ers område. CVE-tal måler derfor offentliggørelsesaktivitet, ikke det reelle antal fejl.

Hvert tal er bygget på CVE-programmets officielle cvelistV5-repository med det snapshot, der blev taget 31. okt. 2026 UTC.

Poster tælles efter offentliggørelsesdato og ikke efter årstallet i CVE-ID'et, da omtrent en femtedel af posterne offentliggøres i et andet år end det, ID'et angiver. Afviste og tilbagetrukne poster er udeladt.

Ikke i sig selv. En Kritisk sårbarhed i en komponent, du leverer, men aldrig kalder, kan være mindre presserende end en Middel på dit offentlige API.

Reel prioritering kræver viden om, hvorvidt den ramte komponent findes i din software, om den sårbare kode kan nås, og om sårbarheden bliver udnyttet. CVSS svarer ikke på nogen af delene.

CRA kræver, at producenter håndterer sårbarheder i hele produktets supportperiode, rapporterer aktivt udnyttede sårbarheder til ENISA inden for 24 timer efter at være blevet opmærksomme på dem og holder den tekniske dokumentation opdateret.

Disse pligter vokser med mængden i denne graf. Det er ikke realistisk at triagere titusindvis af nye poster om året manuelt mod din egen software, og derfor forudsætter CRA reelt en SBOM og en automatiseret matchningsproces.

Du har brug for et præcist inventar over, hvad din software indeholder, og derefter løbende matchning af inventaret mod CVE-feedet.

CRACI genererer en SBOM fra dit build, matcher den mod nye CVE-poster, efterhånden som de offentliggøres, og viser kun de advisories, der når kode, du faktisk leverer, sammen med den dokumentation, CRA forventer, at du opbevarer.

Se, hvordan sårbarhedssporing virker i praksis.