TL; DR
CVE-sikkerhet er praksisen med å spore, prioritere og utbedre sårbarheter ved hjelp av CVE-identifikatorer, standardID-er tilordnet offentlig kjente programvarefeil. Navnelaget fungerer. Analyselaget under holder ikke lenger tritt, og en økende andel av reelle trusler kommer aldri inn i systemet i det hele tatt.
- Volumet vokste ut av analysen. 48 185 CVE-er ble publisert i 2025, omtrent 131 per dag, og innsendingene økte med 263 % mellom 2020 og 2025. Identifikatorene skalerte. Anrikningen gjorde det ikke.
- NVD sluttet å berike alt. Siden april 2026 har NIST kun beriket CVE-er som oppfyller definerte kriterier. Rundt 29 000 etterslepne poster ble omklassifisert som ikke planlagte. Hvis prioriteringen din venter på en NVD CVSS-poengsum, vil en økende andel av CVE-er aldri gi deg en.
- Finansieringsskrekken lukket seg, avhengigheten gjorde det ikke. CISA fornyet programmet etter nesten-avslutningen i april 2025, men den enkeltsponsorstrukturen som forårsaket skremselen er uendret, og CVE Foundation eksisterer på grunn av det.
- Ikke alle trusler får en CVE. En ondsinnet pakke er en artefakt publisert for å forårsake skade, ikke en feil i kode i god tro. Ingen veiledning, ingen poengsum, vanligvis ingen identifikator. Et program bygget på CVE-inntak er blindt for det per design.
- Prioriter kontekst, ikke identifikatoren. Tilgjengelighet, tilgjengelighet av utnyttelser, EPSS og forretningspåvirkning er et viktig funn om hvorvidt CVE-posten noen gang blir komplett eller ikke.
CVE-sikkerhet er praksisen med å spore, prioritere og utbedre sårbarheter ved hjelp av CVE-identifikatorer, standardID-er tilordnet offentlig kjente programvarefeil. Det fungerer fordi alle bruker de samme navnene. Det er under press fordi volumet har vokst ut av infrastrukturen: 48 185 CVE-er ble publisert i 2025, og per april 2026 beriker ikke den nasjonale sårbarhetsdatabasen dem lenger alle.
Denne artikkelen dekker hva CVE-sikkerhet gjør bra, hvor den nå svikter, og hva man skal prioritere når en CVE-ID eller en CVSS-poengsum er forsinket, mangler eller er fraværende per design.
Først: Hva er CVE innen cybersikkerhet?
Dette er et sentralt spørsmål: hva er CVE innen cybersikkerhet?
CVE står for Common Vulnerabilities and Exposures. Det er en standardidentifikator tilordnet kjente programvaresårbarheter. I stedet for å være en database eller en risikopoengsum i seg selv, gir en CVE ganske enkelt hver offentlig sårbarhet en unik identifikator, som CVE-2025-XXXX. Dette muliggjør konsekvent sporing på tvers av verktøy, råd og utbedringsarbeidsflyter.
Hva er så CVE innen cybersikkerhet? I bunn og grunn er det navnekonvensjonen som sikrer at alle team snakker om det samme problemet og bruker samme språk. Dette er avgjørende når man koordinerer responser på tvers av sikkerhet, utvikling og drift. Hvis du vil ha mer, besøk ordlisten vår.
Rollen til CVE-sikkerhet i DevSecOps
I DevSecOps, pipelineog verktøy må samarbeide for å identifisere og håndtere sårbarheter når kode går fra utvikling til produksjon. Hva er limet bak dette økosystemet? CVE-sikkerhet:
- Sårbarhetsskannere: oppdag feil og match dem med CVE-identifikatorer
- Systemer for oppdateringsadministrasjon: de bruker CVE-ID-er for å automatisere utbedring
- Trusselintelligensplattformer: disse beriker CVE-er med data om utnyttbarhet, alvorlighetsgrad og aktivitet
- Samsvarsrapportering: de er avhengige av å spore eksponering for spesifikke CVE-er
Uten en delt identifikator ville disse verktøyene ikke kunne kommunisere effektivt. Dette gjør CVE-sikkerhet ikke bare nyttig, men essensiell for kontinuerlig integrasjon og levering.
En krise innen sårbarhetshåndtering: Problemene med CVE
Konseptet med CVE innen cybersikkerhet er solid, men implementeringen blir stadig mer skjør. CSA fremhevet nylig dette i et blogginnlegg med tittelen A Krise i sårbarhetshåndtering: Problemene med CVE. Denne analysen avdekker tre kritiske problemer:
- Forsinkelser og inkonsekvens: CVE-programmet sliter med å tildele ID-er raskt, spesielt for sårbarheter i åpen kildekode. Som et resultat mangler team ofte rettidige identifikatorer, noe som forsinker triage og patching.
- Ufullstendig dekning: Mange sårbarheter blir ikke oppført i CVE-databasen. Dette skaper hull i deteksjon og åpner organisasjoner for uovervåkede risikoer.
- Avhengighetsskjørhet: Økosystemet har blitt for avhengig av ett enkelt sannhetspunkt. Når CVE-tildelinger er forsinket eller utilgjengelige, kan hele sårbarhetshåndteringen pipeline er forstyrret
Disse systemiske problemene med CVE-sikkerhet fremhever én viktig ting: det presserende behovet for modernisering og andre alternative tilnærminger. Å forstå disse begrensningene hjelper sikkerhetsteam med å unngå blindsoner og utvikle mer robuste praksiser. Se vårt relaterte foredrag på YouTube!
Utfordringer med CVE innen cybersikkerhet
Den økende kompleksiteten i programvareutvikling har overgått mulighetene til det tradisjonelle CVE-systemet. Flere utfordringer definerer nå landskapet til CVE innen cybersikkerhet:
- Volum: CVE ble utviklet for et mindre økosystem. Programmet publiserte 48 185 nye sårbarheter i 2025, en økning på 20.6 % fra 2024s 40 009, og antallet CVE-nummereringsmyndigheter nådde 484 innen januar 2026. Det er omtrent 131 avsløringer per dag. Navngivningslaget har skalert. Analyselaget har ikke.
- Kontekstuelle hull: Mange CVE-er mangler data om utnyttbarhet eller berørte konfigurasjoner, noe som gjør det vanskelig å prioritere.
- Utdaterte poengsystemer: CVSS, poengrammeverket knyttet til mange CVE-er, gjenspeiler ofte ikke reell risiko.
- Finansiering og styring: I april 2025, CISA utførte en kontraktsopsjon kvelden før MITRE-er avtalen utløp, etter at MITRE hadde varslet CVE-styret om at myndighetene ikke hadde til hensikt å fornye den. Finansieringen har siden blitt fornyet, og CISA beskriver nå programmet som fullfinansiert og under modernisering. Spørsmålene om styring er ikke avgjort: CVE-styret fungerer i stor grad som et rådgivende organ, mens MITRE beholder den endelige avgjørelsen.cisioneringsmyndighet, og forespørsler om tilgang til MITRE-CISEn kontrakt, inkludert en FOIA-forespørsel, har ikke blitt besvart. Episoden skapte også CVE Foundation, en ideell organisasjon lansert av styremedlemmer for å oppnå uavhengighet fra én enkelt statlig sponsor.
- Berikelse er ikke lenger universell. 15. april 2026 endret NIST måten NVD opererer på. Nå beriker den bare CVE-er som oppfyller definerte kriterier; resten er oppført, men merket med lavest prioritet og berikes ikke umiddelbart. Alle etterslepne poster med en NVD-publiseringsdato før 1. mars 2026 ble flyttet til «Ikke planlagt». Dette omklassifiserte omtrent 29 000 CVE-er. NISTs forklaring er aritmetisk snarere enn policy: den beriket nesten 42 000 CVE-er i 2025, 45 % mer enn noe tidligere år, og innsendingene overgikk fortsatt den. Hvis prioriteringen din pipeline venter på en NVD CVSS-score, vil en økende andel av nye CVE-er aldri gi deg en.
Alt dette sender oss et klart budskap: CVE-sikkerhet alene er ikke lenger nok.
Ikke alle trusler får en CVE
CVE-samtalen antar at det du sporer er en feil i koden noen har skrevet i god tro. En ondsinnet pakke er ikke det. Det er en artefakt som er laget og publisert for å forårsake skade, og ingen sender inn en advarsel mot den: det finnes ingen CVE, ingen CVSS-poengsum og vanligvis ingen identifikator i det hele tatt. Den er aktiv i minutter til timer, og fjernes deretter.
Konsekvensen er ubehagelig. «Har dette en CVE?» returnerer det samme svaret for en ren pakke og for en legitimasjonstyver publisert for en time siden. Et program som er bygget utelukkende på CVE-inntak, alvorlighetsgrad og oppdateringsvinduer er strukturelt blindt for en hel angrepsklasse, og det er den raskest voksende.
Deteksjon må skje ved publisering snarere enn ved avsløring. Xygenis Malware Early Warning analyserer nylig publiserte pakker på tvers av npm, PyPI, Maven og andre registre i det øyeblikket de dukker opp, ved hjelp av atferds- og anomalianalyse i stedet for å vente på en signatur.
Hvordan kan DevSecOps-team styrke CVE-sikkerhetspraksis?
Selv med sine begrensninger er CVE innen cybersikkerhet fortsatt den standardMen DevSecOps-teamene må gå lenger. Her finner du fem strategier for å forbedre robustheten din:
- Diversifiser kildene dine: Ikke bygg en pipeline med et enkelt feilpunkt. Bruk GitHub Advisory Database, OSV, EU Vulnerability Database som drives av ENISA, og sammen med NVD og MITRE. CISAs KEV-katalog. For europeiske organisasjoner underlagt rapporteringsplikter i henhold til NIS2, DORA eller CRA, er en ikke-amerikansk primærkilde i økende grad et styringsspørsmål snarere enn en preferanse.
- Bruk kontekstbevisst poengsetting: Berik CVE-data med KEV (kjente utnyttede sårbarheter) og EPSS (Utnyttelsesprediksjonspoengsystem) for å bedre forstå risiko
- Automatiser med Precision: Bygg automatisering som ikke bare inntar CVE-er, men anvender logikk basert på bruk, eksponering og kritiskhet
- Utdanning av utviklingsteam: Utviklere trenger ikke bare å vite hva CVE er innen cybersikkerhet, men også hvordan de skal tolke og handle på CVE-data i arbeidsflytene sine.
- Bidra til Åpen Standards: Organisasjoner kan bidra til å forbedre CVE-sikkerheten ved å bli CVE-nummereringsmyndigheter (CNA-er) eller bidra til åpne databaser.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Fremtiden for CVE i en DevSecOps-verden
Utfordringene med CVE innen cybersikkerhet betyr ikke at systemet er foreldet. Det de signaliserer er et behov for utvikling. Sikkerhetsledere og DevSecOps-utøvere må forstå både kraften og fallgruvene ved CVE-sikkerhet for å bygge en skuddsikker og fremtidsklar strategi.
Enten det er gjennom smartere automatisering, en bedre trusselkontekst eller deltakelse i lokalsamfunnets arbeid, avhenger veien videre av å erkjenne at det som er CVE innen cybersikkerhet bare er begynnelsen. Det virkelige målet er å konstruere systemer som går forbi identifikasjon til kontekstualisert forsvar i sanntid.
Hvordan Xygeni styrker CVE-sikkerheten
Xygeni antar ikke at CVE-posten vil ankomme fullstendig eller i tide.
- Prioritering som ikke er avhengig av NVD-berikelse. Reachability-analyse på funksjonsnivå avgjør om utførelse i applikasjonen din faktisk kan nå den sårbare koden, noe som reduserer falske positiver med opptil 70 %. Utnyttelsestilgjengelighet, EPSS og forretningskontekst ligger ved siden av som konfigurerbare stadier i en prioriteringstrakt, opptil åtte av dem. Et funn uten NVD CVSS-poengsum blir fortsatt rangert.
- Dekning for det som ikke har noen CVE. Tidlig varsling om skadelig programvare oppdager skadelige pakker ved publisering, før en signatur eller en veiledning finnes.
- Én kø, inkludert verktøy du allerede kjører. ASPM innhenter funn fra tredjepartsskannere og bruker samme sortering, forklaring og utbedring på dem som på native funn. Du erstatter ikke en stabel for å oppnå prioritering.
- Utbedring med synlige konsekvenser. For hver sårbar avhengighet viser Xygeni hvilke sårbarheter oppgraderingen løser, hvilke nye den introduserer, og om versjonshoppingen ødelegger koden din, og åpner deretter pull request.
- Bevis for forskriften. SBOM og VDR-utgang i SPDX og CycloneDX, artefaktene CRA, NIS2 og DORA ber om.
Konklusjon: Fremtidssikre sårbarhetsstrategien din med smartere CVE-beskyttelse
CVE-sikkerhet vil forbli sentralt for sporing av sårbarheter og koordinering på tvers av team, leverandører og verktøy for håndtering av sårbarheter. Det er det ingen tvil om. Men systemet, slik det er i dag, er skjørt, utsatt for finansieringshull, forsinkelser i tildelinger og ufullstendig kontekst. Å erkjenne begrensningene ved CVE innen cybersikkerhet er det første skrittet mot mer robust og intelligent sårbarhetshåndtering.
Som sikkerhetsekspert må du gå lenger enn bare å spørre hva CVE er innen cybersikkerhet. Du må vurdere hvordan verktøyene, prosessene og menneskene er avhengige av det, og hvordan du kan utvikle disse systemene. Ved å diversifisere datakilder, berike sårbarhetskonteksten og bygge automatisering som tar hensyn til nyanser, kan DevSecOps-team styrke sin holdning og bedre beskytte det som, som vi har sagt tidligere, virkelig betyr noe.
Hva er CVE-sikkerhet?
CVE-sikkerhet er praksisen med å spore, prioritere og utbedre sårbarheter ved hjelp av CVE-identifikatorer, standardID-er tilordnet offentlig kjente programvarefeil. En CVE er ikke en database eller en risikoscore. Det er et delt navn som lar skannere, patchhåndtering, trusselintelligens og samsvarsrapportering referere til det samme problemet.
Hvorfor har noen CVE-er ingen CVSS-skåre?
Fordi den nasjonale sårbarhetsdatabasen ikke lenger beriker alle poster. Siden april 2026 har NIST kun lagt til alvorlighetspoeng og produktdetaljer for CVE-er som oppfyller definerte kriterier; resten er publisert, men merket med lavest prioritet. Omtrent 29 000 etterslepne poster ble omklassifisert som ikke planlagte. En manglende poengsum betyr uanalysert, ikke lav risiko.
Får alle sårbarheter en CVE?
Nei. Mange feil i åpen kildekode blir aldri tildelt en, og en hel trusselklasse befinner seg utenfor systemet per design. Ondsinnede pakker er artefakter publisert for å forårsake skade snarere enn feil i legitim kode, så ingen sender inn en advarsel mot dem. De har vanligvis ingen CVE, ingen poengsum og ingen identifikator i det hele tatt.
