Trender i CVE-publisering

47 802 CVE-oppføringer ble publisert i 2025, opp 20 % fra året før. 2026 har allerede nådd 88 746, og det gjenstår fortsatt måneder.

Volumet har vokst hvert år siden CVE-programmet startet, men veksttakten endret seg kraftig i 2026. Bruk diagrammet over for å se trenden per måned, kvartal eller år.

På denne siden. Diagrammet og tallene over er CVE-statistikk som bygges på nytt hver dag fra CVE-programmets cvelistV5-repositorium, den samme kilden CVE-programmet publiserer fra.

De dekker publiseringsvolum etter CVSS-alvorlighetsgrad, etter tildelende organisasjon og per uke, måned, kvartal eller år, sammen med de nyeste kritiske oppføringene. Vil du se detaljene for én sårbarhet, følger du en identifikator videre til cve.org.

Tre ting skjer samtidig, og de publiserte oppføringene kan ikke skille dem fra hverandre.

Flere organisasjoner kan nå tildele CVE-ID-er, så sårbarheter som tidligere aldri ble registrert, blir nå ført opp. Automatisert og AI-assistert oppdagelse av sårbarheter har økt hvor mye en enkelt forsker kan finne. Og CISAs berikelsesprogram har fylt inn detaljer på eldre oppføringer, noe som endrer historiske tall i etterkant.

Stigende CVE-tall er derfor ikke i seg selv bevis på at programvare blir mindre sikker.

En CNA er en organisasjon som har fullmakt til å tildele CVE-ID-er og publisere oppføringer innenfor sitt eget område, vanligvis sine egne produkter. 497 CNA-er finnes i dette datasettet.

Leverandører, prosjekter med åpen kildekode, bug bounty-plattformer og nasjonale CERT-er fungerer alle som CNA-er. Den største her er mitre, med 39 586 oppføringer. Fordi én CNA som endrer prosessen sin, kan flytte totalene merkbart, lar diagrammet deg filtrere på én organisasjon om gangen.

CVSS gir en sårbarhet en score fra 0,0 til 10,0 og grupperer den i bånd: Lav (0,1-3,9), Middels (4,0-6,9), Høy (7,0-8,9) og Kritisk (9,0-10,0).

Scoren beskriver iboende tekniske egenskaper, for eksempel hvordan sårbarheten nås og hva den kompromitterer. Den er ikke et mål på hvor stor risiko en bestemt organisasjon står overfor.

18.0% av oppføringene publisert siden 2020 har ingen CVSS-score, verken i CNA-ens egne data eller i CISAs berikelse.

Scoring var ikke påkrevd i det meste av CVE-programmets historie. Dekningen blir kraftig bedre fra 2023 og utover og er nå nesten fullstendig, så når Ukjent-feltet i diagrammet krymper, gjenspeiler det en endring i rapporteringspraksis, ikke en endring i selve sårbarhetene. En analyse som ignorerer oppføringer uten score, vil undervurdere eldre år.

En sårbarhet er en feil i programvare. En CVE er en offentlig identifikator som tildeles et bestemt, offentliggjort tilfelle av en slik feil.

De fleste sårbarheter får aldri en CVE: De blir funnet og rettet internt, eller de faller utenfor området til alle CNA-er. CVE-tall måler derfor offentliggjøringsaktivitet, ikke hvor mange feil som faktisk finnes.

Hvert tall er bygget fra CVE-programmets offisielle cvelistV5-repositorium, med øyeblikksbildet tatt 31. okt. 2026 UTC.

Oppføringer telles etter publiseringsdato og ikke etter året i CVE-ID-en, siden omtrent en femtedel av oppføringene publiseres i et annet år enn det identifikatoren oppgir. Avviste og trukne oppføringer er utelatt.

Ikke i seg selv. En kritisk sårbarhet i en komponent du leverer, men aldri kaller, kan haste mindre enn en middels sårbarhet i det offentlige API-et ditt.

Reell prioritering må vite om den berørte komponenten finnes i programvaren din, om den sårbare koden kan nås, og om sårbarheten blir utnyttet. CVSS svarer ikke på noen av delene.

CRA krever at produsenter håndterer sårbarheter gjennom hele produktets støtteperiode, rapporterer aktivt utnyttede sårbarheter til ENISA innen 24 timer etter at de ble kjent med dem, og holder den tekniske dokumentasjonen oppdatert.

Disse pliktene vokser med volumet i dette diagrammet. Å prioritere titusenvis av nye oppføringer i året mot din egen programvare er ikke realistisk manuelt, og derfor forutsetter CRA i praksis en SBOM og en automatisert matcheprosess.

Du trenger en nøyaktig oversikt over hva programvaren din inneholder, og deretter kontinuerlig matching av den oversikten mot CVE-feeden.

CRACI genererer en SBOM fra bygget ditt, matcher den mot nye CVE-oppføringer etter hvert som de publiseres, og viser bare advisoryene som når kode du faktisk leverer, sammen med dokumentasjonen CRA forventer at du beholder.

Se hvordan sporing av sårbarheter fungerer i praksis.