Slik håndterer du stadig flere CVE-er når teamet er lite

Hva som har endret seg: CVE-tallene

Tallene nedenfor kommer fra CVE-programmets egne poster, bygget på nytt hver dag på siden vår om trender i CVE-publisering. Per øyeblikksbildet tatt 12. nov. 2026 UTC:

• 47 801 poster ble publisert i 2025, 20 % flere enn året før.
• 95 494 poster er publisert i 2026 så langt, 303 om dagen, +131 % over dagstakten i 2025.
• 155 om dagen har alvorlighetsgrad High eller Critical.
• 17 % av alle poster siden 2020 har ingen CVSS-score, verken fra den som tildelte dem eller fra CISAs berikelse. Dekningen har blitt bedre: I 2026 er andelen 6 %.
• 505 organisasjoner tildelte disse postene, og de 20 største står for 75 % av dem.

• High eller Critical
• Andre alvorlighetsgrader og uten score

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

Daglig gjennomsnitt av poster publisert hvert år; * markerer inneværende år så langt. Kilde: CVE-programmets cvelistV5-poster, øyeblikksbilde 12. nov. 2026 UTC. Filtrer etter måned, alvorlighetsgrad og tildeler: trender i CVE-publisering.

Dette er ikke et dårlig kvartal. Antallet har økt hvert år siden 2020, og flere strukturelle endringer holder det oppe:

• Flere tildelere, som tildeler bredere. Linux-kjerneprosjektet ble en CVE Numbering Authority i februar 2024. Den dokumenterte policyen er å tildele en CVE til enhver feilretting som kan være en sårbarhet, så snart rettingen når en stabil kjerne, fordi det ofte er uklart om feilen kan utnyttes når rettingen kommer. Kjernens CNA alene har publisert 18 221 poster siden.
• KI-assistert oppdagelse. I november 2024 rapporterte Googles Project Zero og DeepMind at agenten Big Sleep hadde funnet en utnyttbar minnesikkerhetsfeil i SQLite før den nådde en utgivelse, noe de mener var det første offentlige eksempelet på at en KI-agent gjorde dette i mye brukt programvare. Slike verktøy øker hvor mye én forsker kan finne.
• NVD klarer ikke lenger å berike alt. NIST opplyser at National Vulnerability Database bygde opp et etterslep av uberikede CVE-er fra tidlig i 2024 og ikke klarte å ta det igjen etter hvert som innsendingene økte. I april 2026 gikk den over til en risikobasert modell: CVE-er i CISAs katalog over Known Exploited Vulnerabilities og CVE-er i føderal eller kritisk programvare berikes først, og resten oppføres som ikke planlagt for umiddelbar berikelse. En prosess som er avhengig av én databases data om berørte produkter, venter nå, eller går glipp av noe.
• Kortere tid til å reagere. Mandiant målte en gjennomsnittlig tid til utnyttelse på 63 dager i 2018 og 2019. M-Trends 2026-rapporten anslår minus sju dager for 2025: Utnyttelse starter nå rutinemessig før en patch er utgitt.
• Regulatoriske frister. Under EUs Cyber Resilience Act skal produsenter rapportere en aktivt utnyttet sårbarhet med et tidlig varsel innen 24 timer, en melding innen 72 timer og en sluttrapport innen 14 dager etter at en retting er tilgjengelig (hva CRA krever). Fristen er den samme for et team på tre som for et team på tre hundre.

Ingenting av dette betyr at programvare blir mindre sikker. Det betyr at antallet ting et team må se på, vokser hvert år, mens teamet ikke gjør det.

Hva som bryter sammen i et lite teams prosess

Økende antall bryter ikke sårbarhetshåndteringen fordi det er flere sårbarheter å rette. Det bryter den fordi hvert manuelle steg gjentas for hver CVE.

Manuelt steg	Hvorfor det svikter med dagens volum
Bygge oversikten for hånd	Et regneark, eller en SBOM laget før en revisjon, er utdatert dagen etter neste utgivelse.
Lese strømmen	Med 155 poster med High eller Critical om dagen klarer ingen å henge med.
Spørre utviklerne «bruker vi X?»	Det samme spørsmålet for hver CVE, til de samme travle folkene. Spørsmålet er flaskehalsen.
Én sak per CVE per repositorium	En CVE i et delt bibliotek blir til dusinvis av dupliserte saker som drukner backloggen.
Svare hver kunde enkeltvis	Henvendelsene vokser med kundebasen, ikke med antallet sårbarheter.
Dokumenter i PDF eller på en wiki	Kundenes verktøy kan ikke matche en PDF mot oversikten sin, så hver leser spør på nytt.
Frister som ikke flytter seg	Tiden til utnyttelse krymper, mens en manuell prosess blir tregere etter hvert som volumet vokser.

Oversikten. De fleste team som fører en komponentliste for hånd, oppdaterer den før en revisjon eller et spørreskjema fra en kunde. Mellom disse datoene beskriver den programvare som ikke lenger leveres. Hvert CVE-spørsmål begynner da med å gjenskape hva utgivelsen inneholdt.

Strømmen. Å lese sikkerhetsvarsler er steget team begynner med, og det første som kollapser. Vi hører fra team som fortsatt gjør det for hånd, blant annet ett der sårbarhetsskanning betyr at folk leser CVE-fora. Det fungerer helt til den dagen det ikke gjør det, og det finnes ikke noe signal for den dagen.

Spørsmålet til utviklerne. «Bruker vi dette biblioteket, og hvilken versjon?» avbryter en utvikler for hver CVE som kan være relevant. Et produktsikkerhetsteam på to personer fortalte oss at arbeidet består i å trykke på knapper bare for å henge med, uten tid igjen til å forbedre prosessen.

Sakene. Når et delt bibliotek har en CVE og hvert repositorium åpner sin egen sak, teller backloggen den samme beslutningen mange ganger. Team lærer seg å ignorere backloggen, og går så glipp av saken som betydde noe.

Kundesvarene. Etter en mye omtalt sårbarhet eller et forsyningskjedeangrep spør kundene «er vi berørt?». Å svare hver enkelt for seg koster mest tid den dagen det er minst av den.

Dokumentene. En PDF-erklæring eller en wikiside må leses av en person hos kunden. Kundenes skannere, og i økende grad myndighetene, forventer SBOM-er, VEX og sikkerhetsvarsler i formater en maskin kan matche.

Fristene. Et tidlig varsel som skal leveres innen 24 timer, eller en exploit som dukker opp før patchen, venter ikke på at køen skal bli tom.

Hva du bør automatisere, i rekkefølge

Hvert steg fjerner arbeid fra det neste, så rekkefølgen betyr mer enn valget av verktøy.

1. Vit hva du leverer. En SBOM fra hvert bygg gjør «er vi berørt?» til et oppslag.
2. Match kontinuerlig, mot mer enn én kilde. Nye CVE-er sjekkes mot hver lagret SBOM, så ingen trenger å lese strømmen.
3. Kutt støyen. Funn for ting du ikke leverer, og duplikater, når aldri en person.
4. Triager halvautomatisk. Fakta fylles inn; en person tar beslutningen.
5. Gjør alt maskinlesbart. Hver beslutning tas én gang og gjenbrukes av alle som leser den.
6. Svar én gang, offentlig. Henvendelsen som aldri kommer, koster ingenting.

1. Generer en SBOM for hvert bygg, automatisk

Hva det erstatter: regnearket, og spørsmålet til utviklerne. En SBOM generert under bygget beskriver hva bygget faktisk brukte, og når du beholder én per levert versjon, kan du svare for fjorårets utgivelse like godt som for main. Kunder kjører gamle versjoner; oversikten din må dekke dem.

Minimumsversjon: en SBOM generert i CI for hvert utgivelsesbygg, lagret ved siden av utgivelsesartefakten. Bedre: en SBOM registrert fra selve bygget i stedet for utledet fra lockfiler i etterkant, så komponenter hentet utenfor pakkebehandleren også kommer med (SBOM-er fra byggetidspunktet, SBOM-automatisering).

Kostnad: en dag eller to med pipelinearbeid for minimumsversjonen, deretter ingenting per utgivelse. Tegn på at det virker: For enhver utgivelse kan du liste komponentene uten å spørre noen.

2. Match kontinuerlig mot flere sårbarhetskilder

Hva det erstatter: å lese strømmen. Matching er en jobb for en maskin: hver ny CVE mot hver lagret SBOM, ikke bare SBOM-en fra bygget som nettopp kjørte. En gammel utgivelse som var ren da den ble levert, er berørt den dagen en CVE publiseres for en av komponentene i den.

Én kilde er ikke nok. Etterslepet i NVDs berikelse betyr at data om berørte produkter kan komme sent eller ikke i det hele tatt. Økosystemenes egne sikkerhetsvarsler, som GitHub Advisory Database og OSV, er ofte raskere og oppgir hvilke pakkeversjoner som er berørt, med økosystemets egne begreper. ENISAs EU Vulnerability Database legger til EU-kontekst.

Minimumsversjon: en planlagt jobb som skanner hver lagret SBOM på nytt daglig mot en samlet kilde og rapporterer nye treff. Tegn på at det virker: Du får vite at en utgivelse er berørt før en kunde forteller deg det. Se sårbarhetssporing for hvordan dette ser ut i CRACI.

3. Kutt støyen før noen ser på den

Hva det erstatter: manuell gjennomgang av funn som ikke betyr noe. Det meste av støyen oppstår tidligere i kjeden: i oversikter som lister ting du ikke leverer, når flere verktøy rapporterer den samme CVE-en, og i avhengigheter ingen trenger. Rett opp oversikten, tell hvert funn én gang etter pakke-URL (PURL), versjon og CVE, lever færre avhengigheter, og legg deretter til kontekst om utnyttbarhet fra CISA KEV, EPSS og VEX. Slik reduserer du støy i sårbarhetshåndteringen tar for seg disse grepene ett for ett. Tegn på at det virker: Antallet funn per levert utgivelse faller, og begrunnelsene er dokumentert.

4. Triager halvautomatisk

Hva det erstatter: at en person samler inn fakta for hvert funn. Del opp arbeidet presist:

• Automatisk: alvorlighetsgrad, om den er kjent utnyttet, hvilke produkter og versjoner som inneholder komponenten, eierteamet, en foreslått prioritet og en frist.
• Menneskelig: beslutningen. Rette, begrense, akseptere med utløpsdato, eller markere som ikke berørt med en begrunnelse.

Det som ikke er trygt å automatisere: å lukke et funn som ikke berørt uten en dokumentert begrunnelse. Det er undertrykking, og det kommer tilbake i en revisjon eller en hendelse. Regler for rangering dekkes i prioritering av sårbarheter.

Minimumsversjon: 15 minutter om dagen på en kø som allerede er sortert og fylt ut. Tegn på at det virker: Hver beslutning har en dokumentert begrunnelse, og ingenting venter på at noen skal slå noe opp.

5. Gjør alt maskinlesbart

Hva det erstatter: PDF-er, wikisider og e-poster som en person må lese. Publiser SBOM-er i CycloneDX eller SPDX (CycloneDX vs. SPDX), beslutninger om at noe ikke er berørt som VEX, og sikkerhetsvarsler i CSAF. Kundenes skannere og myndighetene kan da ta dem i bruk uten et menneske, så hver beslutning tas én gang og gjenbrukes av alle som spør.

Minimumsversjon for et lite team: SBOM-er og VEX på forespørsel, fra et fast sted; CSAF når kundene begynner å be om det. Tegn på at det virker: Kundenes verktøy slutter å flagge det du allerede har svart på.

6. Svar én gang, offentlig

Hva det erstatter: én e-posttråd per kunde. Publiser et sikkerhetsvarsel eller en statusside for hver betydelig CVE, med berørte og rettede versjoner, og ha en svarmal som lenker til den. Veiledningen om å svare på «er vi berørt av denne CVE-en?» viser hvordan du finner svaret. For selve svaret har slik svarer du kunder etter et leverandørkjedeangrep svarmaler. Den billigste henvendelsen er den som aldri kommer. Tegn på at det virker: De fleste henvendelser besvares med en lenke.

Deretter: rett

Automatiske pull requests for avhengighetsoppdateringer holder rutinearbeidet i gang; samle dem per uke eller per utgivelse, så gjennomgangen forblir håndterbar. Å oppgradere én pakke lenger opp i kjeden fjerner ofte flere sårbare transitive avhengigheter på én gang, og er billigere enn å patche hver enkelt (automatisert utbedring av sårbarheter). Hindre deretter at nye kjente dårlige komponenter kommer tilbake, med policy gates som blokkerer bygget.

En plan etter teamstørrelse

Timene er illustrative anslag for planlegging, ikke referansetall.

	Én person, deltid	En sikkerhets- eller PSIRT-funksjon på 2 til 5 personer	Et større team
Automatiser først	Steg 1 og 2: en SBOM per bygg og kontinuerlig matching	Steg 1 til 3, deretter ruting til eiere i steg 4	Alle seks, med policy gates i hver pipeline
Forblir manuelt	Beslutningen om hvert funn med High eller Critical; kundesvar fra en mal	Beslutninger, VEX-begrunnelser, sikkerhetsvarsler for betydelige CVE-er	Beslutninger, unntak og selve prosessen
Ukentlig tid, illustrativt	2 til 4 timer	4 til 8 timer per person	Styrt av beslutningsvolumet, ikke av strømmen

Hvis du allerede driver et PSIRT, gjelder den samme rekkefølgen; den fullstendige prosessmodellen finner du i livssyklusen for sårbarhetshåndtering. For kundehenvendelsene som blir flere for hver CVE, se slik skalerer du et PSIRT.

Slik vet du at det virker

• Tid fra en CVE publiseres til «berørt» eller «ikke berørt», per produkt.
• Andelen kundehenvendelser som besvares med publisert materiale.
• Funn per levert utgivelse, ikke per skanning.
• Andelen beslutninger med en dokumentert begrunnelse.
• Timer per uke brukt på sårbarhetsarbeid, og om tallet faller.

Mål ditt eget utgangspunkt først. Det finnes ingen pålitelige bransjetall for disse, og vi oppgir ingen.

Ansette, kjøpe eller endre prosessen?

• Ansett når arbeidet er å rette sårbarheter i din egen kode, eller kundevendt sikkerhetsarbeid som krever skjønn.
• Kjøp verktøy for stegene som gjentas for hver CVE: steg 1, 2, 3 og 5.
• Endre prosessen for eierskap og frister: hvem som bestemmer, og innen når.

Vær ærlig om det siste. Et verktøy uten eier gir et dashbord ingen leser.

Hvor CRACI passer inn

CRACI automatiserer steg 1 og 2, og deler av steg 3 og 4, for programvare som bygges i GitHub Actions. CRACI erstatter de GitHub-hostede runnerne dine, og mens hver jobb kjører, registrerer CRACI pakkene jobben faktisk hentet inn, inkludert pakker gjenopprettet fra CI-cacher og skjulte avhengigheter som ingen lockfile lister opp.

• En SBOM fra hvert bygg. Hver jobbs SBOM identifiserer hver komponent med PURL og har en fullstendighetsstatus, så du vet når noe ikke kunne registreres. Byggehistorikken tar vare på hvert tidligere bygg med tilhørende SBOM, så du kan se hvilke bygg som inneholdt en sårbar avhengighet, direkte eller transitiv.
• Kontinuerlig matching. Overvåkede SBOM-er vurderes på nytt fortløpende, og funn samles på tvers av bygg og repositorier, så en CVE i et delt bibliotek vises som ett problem, ikke førti.
• Varsler og gates. CRACI varsler de relevante personene om en sårbarhet og alvorlighetsgraden, og policy gates kan stoppe et bygg i sanntid, også et bygg som inneholder en bestemt CVE.
• Triage og tildeling. Sikkerhetsteam triagerer funn i CRACI og sender hvert funn til teamet som eier rettingen.
• Maskinlesbare SBOM-er. SBOM-er eksporteres som CycloneDX eller SPDX, og CRACI støtter VEX.

CRACI publiserer ikke sikkerhetsvarsler, tilbyr ikke reachability-analyse og skanner ikke din egen kode. CRACI tar bare betalt for byggeminutter: $0.002 per vCPU-minutt ($0.004 for en standard runner med 2 vCPU), målt per sekund, uten månedsavgift, uten kostnad per SBOM og foreløpig uten lisensavgift. Se priser.

Automatiser de to første stegene i dag: kjør byggene dine på CRACI. Vi tar imot hvert team personlig før generell tilgjengelighet.

Når CRACI ikke er svaret

• Programvaren din bygges ikke i GitHub Actions. GitLab CI og Jenkins står på veikartet.
• Eksponeringen din gjelder hovedsakelig infrastruktur: servere, endepunkter og skykonfigurasjon. Verktøy for sårbarhetshåndtering av infrastruktur passer bedre.
• Du integrerer fastvare fra tredjeparter som du ikke bygger selv. Verktøy for binæranalyse passer bedre.
• Backloggen din består for det meste av ekte, utnyttbare funn i din egen kode. Det er et problem med kapasitet til å rette, ikke et automatiseringsproblem.

Automatisering av sårbarhetshåndtering: ofte stilte spørsmål

Hvorfor er det så mange flere CVE-er nå?

Flere organisasjoner tildeler CVE-er, og noen tildeler dem bredt: Linux-kjernen ble en CVE Numbering Authority i 2024 og tildeler en til enhver feilretting som kan være en sårbarhet. KI-assisterte verktøy finner flere feil per forsker. 47 801 poster ble publisert i 2025, og 2026 ligger på 303 om dagen. Trenden har vart i årevis.

Hvordan kan et lite team holde tritt med nye CVE-er?

Ved å ikke lese dem. Generer en SBOM for hvert bygg, match nye CVE-er automatisk mot hver lagret SBOM, kutt støyen, og la folk bare ta beslutningene om det som er igjen. Et lite team holder tritt ved å fjerne stegene som gjentas for hver CVE, ikke ved å jobbe raskere.

Hva bør vi automatisere først i sårbarhetshåndteringen?

Oversikten: en SBOM generert i CI for hvert utgivelsesbygg, lagret sammen med utgivelsen. Hvert senere steg er avhengig av den, og den gjør «er vi berørt?» fra et spørsmål til utviklerne til et oppslag. Kontinuerlig matching mot disse SBOM-ene kommer som nummer to.

Trenger vi et sikkerhetsteam for å håndtere sårbarheter?

Ikke for å komme i gang. Én person som eier prosessen på deltid, kan drive den hvis oversikten, matchingen og støyreduksjonen er automatisert. Du trenger en navngitt eier og frister mer enn et team. Ansett når arbeidet blir å rette din egen kode eller kundevendt sikkerhetsarbeid.

Hvordan vet vi hvilke nye CVE-er som berører produktet vårt?

Behold en SBOM for hver levert versjon og sjekk alle på nytt hver gang nye CVE-er publiseres, mot mer enn én sårbarhetskilde. En CVE berører deg når den matcher en komponent og versjon du faktisk leverer. Kontekst om utnyttbarhet og VEX forteller deretter om den betyr noe.

Hva betyr «maskinlesbar» for SBOM-er, VEX og sikkerhetsvarsler, og hvorfor er det viktig?

Det betyr et standardisert, strukturert format et verktøy kan tolke: CycloneDX eller SPDX for SBOM-er, VEX for erklæringer om at noe ikke er berørt, CSAF for sikkerhetsvarsler. En kundes skanner kan matche dem mot sin egen oversikt uten at noen leser dem, så en beslutning du tar én gang, gjenbrukes av hver kunde og hvert verktøy.

Hvor mye av triagen kan automatiseres trygt?

Innsamlingen av fakta: alvorlighetsgrad, om den utnyttes, hvilke produkter og versjoner som inneholder komponenten, eieren, en foreslått prioritet og en frist. Selve beslutningen bør ligge hos en person. Lukk aldri et funn automatisk som ikke berørt uten en dokumentert begrunnelse.

Hvor lang tid har vi på å reagere på en kritisk CVE?

Mindre enn de fleste prosesser antar. Mandiants M-Trends 2026 anslår gjennomsnittlig tid til utnyttelse i 2025 til minus sju dager, altså utnyttelse før en patch finnes. Under EUs Cyber Resilience Act krever en aktivt utnyttet sårbarhet et tidlig varsel innen 24 timer. Sett din egen frist etter alvorlighetsgrad og utnyttelse, og mål deg mot den.