Sådan håndterer du stigende CVE-tal, når dit team er lille

Hvad har ændret sig: CVE-tallene

Tallene nedenfor kommer fra CVE-programmets egne poster og genberegnes hver dag på vores side om tendenser i CVE-offentliggørelser. Ifølge øjebliksbilledet fra 12. nov. 2026 UTC:

• 47.801 poster blev offentliggjort i 2025, 20 % flere end året før.
• 95.494 poster er indtil videre offentliggjort i 2026, 303 om dagen, +131 % i forhold til den daglige rate i 2025.
• 155 om dagen har alvorligheden Høj eller Kritisk.
• 17 % af alle poster siden 2020 har ingen CVSS-score, hverken fra den, der tildelte dem, eller fra CISA's berigelse. Dækningen er blevet bedre: I 2026 er andelen 6 %.
• 505 organisationer har tildelt disse poster, og de 20 største står for 75 % af dem.

• Høj eller Kritisk
• Andre alvorligheder og uden score

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

Dagligt gennemsnit af poster offentliggjort i hvert år; * markerer indeværende år til dato. Kilde: CVE-programmets cvelistV5-poster, øjebliksbillede 12. nov. 2026 UTC. Filtrer efter måned, alvorlighed og tildeler: tendenser i CVE-offentliggørelser.

Det er ikke et dårligt kvartal. Tallet er steget hvert år siden 2020, og flere strukturelle ændringer får det til at blive ved med at stige:

• Flere tildelere, der tildeler bredere. Linux-kerneprojektet blev CVE Numbering Authority i februar 2024. Dets dokumenterede politik er at tildele en CVE til enhver fejlrettelse, der kan være en sårbarhed, når rettelsen når en stabil kerne, fordi det ofte ikke er klart, om noget kan udnyttes, når en rettelse lander. Kernens CNA alene har offentliggjort 18.221 poster siden.
• AI-assisteret opdagelse. I november 2024 rapporterede Googles Project Zero og DeepMind, at deres Big Sleep-agent havde fundet en udnyttelig hukommelsesfejl i SQLite, før den nåede en release. De mener, det var det første offentlige eksempel på, at en AI-agent har gjort det i udbredt software. Værktøjer som det øger, hvor meget én forsker kan finde.
• NVD kan ikke længere berige alt. Ifølge NIST opbyggede National Vulnerability Database fra starten af 2024 en pukkel af uberigede CVE'er og kunne ikke afvikle den, mens indsendelserne blev ved med at stige. I april 2026 gik den over til en risikobaseret model: CVE'er i CISA's katalog over Known Exploited Vulnerabilities og CVE'er i føderal eller kritisk software beriges først, og resten opføres som ikke planlagt til umiddelbar berigelse. En proces, der er afhængig af én databases data om berørte produkter, venter nu, eller overser noget.
• Mindre tid til at reagere. Mandiant målte en gennemsnitlig tid til udnyttelse på 63 dage i 2018 og 2019. Dets M-Trends 2026-rapport anslår minus syv dage for 2025: Udnyttelse begynder nu rutinemæssigt, før en patch er udgivet.
• Lovgivningens ure. Under EU's Cyber Resilience Act rapporterer producenter en aktivt udnyttet sårbarhed med en tidlig advarsel inden for 24 timer, en underretning inden for 72 timer og en endelig rapport inden for 14 dage efter, at en rettelse er tilgængelig (hvad CRA kræver). Uret er det samme for et team på tre som for et team på tre hundrede.

Intet af dette betyder, at software bliver mindre sikker. Det betyder, at antallet af ting, et team skal se på, vokser hvert år, mens teamet ikke gør.

Hvad der bryder sammen i et lille teams proces

Stigende tal får ikke sårbarhedsstyringen til at bryde sammen, fordi der er flere sårbarheder at rette. De får den til at bryde sammen, fordi hvert manuelt trin gentages for hver CVE.

Manuelt trin	Hvorfor det slår fejl ved nutidens mængde
At bygge inventaret manuelt	Et regneark, eller en SBOM lavet før en audit, er forældet dagen efter næste release.
At læse feedet	Ved 155 poster om dagen med Høj eller Kritisk kan ingen følge med.
At spørge udviklingsafdelingen "bruger vi X?"	Det samme spørgsmål for hver CVE, til de samme travle mennesker. Spørgsmålet er flaskehalsen.
Én ticket pr. CVE pr. repository	En CVE i et delt bibliotek bliver til dusinvis af dublerede tickets, der oversvømmer backloggen.
At svare hver kunde for sig	Henvendelserne vokser med kundebasen, ikke med antallet af sårbarheder.
Dokumenter i PDF eller en wiki	Kundernes værktøjer kan ikke matche en PDF mod deres inventar, så hver læser spørger igen.
Frister, der ikke flytter sig	Tiden til udnyttelse skrumper, mens en manuel proces bliver langsommere, efterhånden som mængden vokser.

Inventaret. De fleste teams, der fører en komponentliste manuelt, opdaterer den før en audit eller et spørgeskema fra en kunde. Mellem de datoer beskriver den software, der ikke længere leveres. Hvert CVE-spørgsmål begynder så med at genskabe, hvad releasen indeholdt.

Feedet. At læse advisories er det trin, teams starter med, og det første, der bryder sammen. Vi hører fra teams, der stadig gør det manuelt, blandt andet et, hvor sårbarhedsscanning betyder, at folk læser CVE-fora. Det virker indtil den dag, det ikke gør, og der er intet signal for den dag.

Spørgsmålet til udviklingsafdelingen. "Bruger vi det her bibliotek, og i hvilken version?" afbryder en udvikler for hver CVE, der måske gælder. Et produktsikkerhedsteam på to personer fortalte os, at arbejdet består i at trykke på knapper bare for at følge med, uden tid tilbage til at forbedre processen.

Ticketsene. Når et delt bibliotek har en CVE, og hvert repository åbner sin egen ticket, tæller backloggen den samme beslutning mange gange. Teams lærer at ignorere backloggen og overser så den ticket, der betød noget.

Svarene til kunderne. Efter en meget omtalt sårbarhed eller et supply chain-angreb spørger kunderne: "Er vi berørt?". At svare hver enkelt for sig koster mest tid den dag, der er mindst af den.

Dokumenterne. En erklæring i PDF eller en wikiside skal læses af et menneske hos kunden. Kundernes scannere, og i stigende grad myndighederne, forventer SBOM'er, VEX og advisories i formater, en maskine kan matche.

Fristerne. En tidlig advarsel, der skal sendes inden for 24 timer, eller et exploit, der dukker op før patchen, venter ikke på, at køen bliver tømt.

Hvad du skal automatisere, i rækkefølge

Hvert trin fjerner arbejde fra det næste, så rækkefølgen betyder mere end valget af værktøjer.

1. Ved, hvad du leverer. En SBOM fra hvert build gør "er vi berørt?" til et opslag.
2. Match løbende, mod mere end én kilde. Nye CVE'er tjekkes mod hver gemt SBOM, så ingen læser feedet.
3. Skær støjen væk. Fund for ting, du ikke leverer, og dubletter når aldrig et menneske.
4. Triager halvautomatisk. Fakta er udfyldt; et menneske træffer beslutningen.
5. Gør alt maskinlæsbart. Hver beslutning træffes én gang og genbruges af alle læsere.
6. Svar én gang, offentligt. Den henvendelse, der aldrig kommer, koster ingenting.

1. Generér automatisk en SBOM for hvert build

Hvad det erstatter: regnearket og spørgsmålet til udviklingsafdelingen. En SBOM genereret ved build beskriver, hvad buildet faktisk brugte, og når du gemmer én pr. leveret version, kan du svare for sidste års release lige så vel som for main. Kunder kører gamle versioner; dit inventar skal dække dem.

Minimumsversion: en SBOM genereret i CI for hvert release-build, gemt ved siden af release-artefaktet. Bedre: en SBOM registreret fra selve buildet frem for udledt af lockfiles bagefter, så komponenter hentet uden om pakkehåndteringen også er med (build-time SBOM'er, SBOM-automatisering).

Omkostning: en dag eller to med pipeline-arbejde for minimumsversionen, derefter intet pr. release. Tegn på, at det virker: For enhver release kan du liste dens komponenter uden at spørge nogen.

2. Match løbende mod flere sårbarhedskilder

Hvad det erstatter: at læse feedet. Matchning er en maskines job: hver ny CVE mod hver gemt SBOM, ikke kun SBOM'en fra det build, der lige har kørt. En gammel release, der var ren, da den blev leveret, er berørt den dag, der offentliggøres en CVE for en af dens komponenter.

Én kilde er ikke nok. NVD's pukkel af uberigede poster betyder, at data om berørte produkter kan komme sent eller slet ikke. Økosystemernes advisories, som GitHub Advisory Database og OSV, er ofte hurtigere og angiver, hvilke pakkeversioner der er berørt, i økosystemets egne termer. ENISA's EU Vulnerability Database tilføjer EU-kontekst.

Minimumsversion: et planlagt job, der dagligt genscanner hver gemt SBOM mod en samlet kilde og rapporterer nye match. Tegn på, at det virker: Du opdager, at en release er berørt, før en kunde fortæller dig det. Se sårbarhedssporing for, hvordan det ser ud i CRACI.

3. Skær støjen væk, før nogen kigger

Hvad det erstatter: manuel gennemgang af fund, der ikke betyder noget. Det meste støj opstår længere oppe i kæden: i inventarer, der lister ting, du ikke leverer, i flere værktøjer, der rapporterer den samme CVE, og i afhængigheder, ingen har brug for. Ret inventaret, tæl hvert fund én gang efter package URL (PURL), version og CVE, lever færre afhængigheder, og tilføj derefter kontekst om udnyttelighed fra CISA KEV, EPSS og VEX. Sådan reducerer du støjen fra sårbarhedsfund gennemgår håndtagene ét ad gangen. Tegn på, at det virker: Antallet af fund pr. leveret release falder, og årsagerne er registreret.

4. Triager halvautomatisk

Hvad det erstatter: at et menneske samler fakta for hvert fund. Del arbejdet præcist op:

• Automatisk: alvorlighed, om den vides at blive udnyttet, hvilke produkter og versioner der indeholder komponenten, det ansvarlige team, en foreslået prioritet og en frist.
• Menneskeligt: beslutningen. Ret, afbød, acceptér med en udløbsdato, eller markér som ikke berørt med en begrundelse.

Det er ikke sikkert at automatisere: at lukke et fund som ikke berørt uden en registreret begrundelse. Det er undertrykkelse, og det kommer tilbage ved en audit eller en hændelse. Regler for rangering er beskrevet under prioritering af sårbarheder.

Minimumsversion: 15 minutter om dagen med en kø, der allerede er sorteret og udfyldt. Tegn på, at det virker: Hver beslutning har en registreret begrundelse, og intet venter på, at nogen slår noget op.

5. Gør alt maskinlæsbart

Hvad det erstatter: PDF'er, wikisider og e-mails, som et menneske skal læse. Offentliggør SBOM'er i CycloneDX eller SPDX (CycloneDX vs SPDX), beslutninger om ikke berørt som VEX og advisories i CSAF. Så kan kundernes scannere og myndighederne bruge dem uden et menneske, og hver beslutning træffes én gang og genbruges af alle, der spørger.

Minimumsversion for et lille team: SBOM'er og VEX på forespørgsel, fra et fast sted; CSAF, når kunderne begynder at spørge efter det. Tegn på, at det virker: Kundernes værktøjer holder op med at markere det, du allerede har besvaret.

6. Svar én gang, offentligt

Hvad det erstatter: én e-mailtråd pr. kunde. Offentliggør en advisory eller en statusside for hver væsentlig CVE med de berørte og rettede versioner, og hav en svarskabelon, der linker til den. Guiden til at besvare "er vi berørt af denne CVE?" viser, hvordan du finder frem til svaret. Til selve svaret har sådan svarer du kunder efter et forsyningskædeangreb svarskabeloner. Den billigste henvendelse er den, der aldrig kommer. Tegn på, at det virker: De fleste henvendelser besvares med et link.

Ret derefter

Automatiske pull requests med opdateringer af afhængigheder holder rutinearbejdet i gang; saml dem pr. uge eller pr. release, så gennemgangen forbliver overkommelig. En opgradering af én upstream-pakke fjerner ofte flere sårbare transitive afhængigheder på én gang og er billigere end at patche hver enkelt (automatiseret afhjælpning af sårbarheder). Forhindr derefter, at nye kendt dårlige komponenter vender tilbage, med policy gates, der blokerer buildet.

En plan efter teamets størrelse

Timetallene er illustrative estimater til planlægning, ikke benchmarks.

	Én person, på deltid	En sikkerheds- eller PSIRT-funktion på 2 til 5 personer	Et større team
Automatisér først	Trin 1 og 2: en SBOM pr. build og løbende matchning	Trin 1 til 3, derefter fordeling til ejere i trin 4	Alle seks, med policy gates i hver pipeline
Forbliver manuelt	Beslutningen om hvert fund med Høj eller Kritisk; svar til kunder ud fra en skabelon	Beslutninger, VEX-begrundelser, advisories for væsentlige CVE'er	Beslutninger, undtagelser og selve processen
Tid pr. uge, illustrativt	2 til 4 timer	4 til 8 timer pr. person	Bestemt af mængden af beslutninger, ikke af feedet

Hvis du allerede driver et PSIRT, gælder den samme rækkefølge; den fulde procesmodel findes i livscyklussen for sårbarhedsstyring. Om de kundehenvendelser, der bliver flere for hver CVE, kan du læse i at skalere et PSIRT.

Sådan ved du, at det virker

• Tiden fra en CVE offentliggøres til "berørt" eller "ikke berørt", pr. produkt.
• Andelen af kundehenvendelser, der besvares ud fra offentliggjort materiale.
• Fund pr. leveret release, ikke pr. scanning.
• Andelen af beslutninger med en registreret begrundelse.
• Timer pr. uge brugt på sårbarhedsarbejde, og om tallet falder.

Mål først dit eget udgangspunkt. Der findes ingen pålidelige branchebenchmarks for disse tal, og vi citerer ingen.

Ansætte, købe eller ændre processen?

• Ansæt, når arbejdet er at rette sårbarheder i din egen kode, eller sikkerhedsarbejde over for kunder, der kræver dømmekraft.
• Køb værktøjer til de trin, der gentages for hver CVE: trin 1, 2, 3 og 5.
• Ændr processen for ejerskab og frister: hvem der beslutter, og hvornår.

Vær ærlig om det sidste. Et værktøj uden en ejer giver et dashboard, som ingen læser.

Hvor CRACI passer ind

CRACI automatiserer trin 1 og 2 og dele af trin 3 og 4 for software, der bygges i GitHub Actions. Det erstatter dine GitHub-hostede runnere, og mens hvert job kører, registrerer det de pakker, jobbet faktisk hentede, inklusive pakker gendannet fra CI-caches og skjulte afhængigheder, som ingen lockfile lister.

• En SBOM fra hvert build. Hvert jobs SBOM identificerer hver komponent med en PURL og har en fuldstændighedsstatus, så du ved, hvornår noget ikke kunne ses. Build-historikken gemmer hvert tidligere build med dets SBOM, så du kan se, hvilke builds der indeholdt en sårbar afhængighed, direkte eller transitiv.
• Løbende matchning. Overvågede SBOM'er genvurderes løbende, og fund samles på tværs af builds og repositories, så en CVE i et delt bibliotek viser sig som ét problem, ikke fyrre.
• Notifikationer og gates. CRACI giver de relevante personer besked om en sårbarhed og dens alvorlighed, og policy gates kan stoppe et build i realtid, også et build, der indeholder en bestemt CVE.
• Triage og tildeling. Sikkerhedsteams triagerer fund i CRACI og sender hvert fund til det team, der ejer rettelsen.
• Maskinlæsbare SBOM'er. SBOM'er eksporteres som CycloneDX eller SPDX, og CRACI understøtter VEX.

CRACI offentliggør ikke advisories, tilbyder ikke reachability-analyse og scanner ikke din egen kode. Det tager kun betaling for build-minutter: $0.002 pr. vCPU-minut ($0.004 for en standardrunner med 2 vCPU), målt pr. sekund, uden månedligt gebyr, uden betaling pr. SBOM og uden licensgebyr lige nu. Se priser.

Automatisér de to første trin i dag: kør dine builds på CRACI. Vi onboarder hvert team personligt før general availability.

Når CRACI ikke er svaret

• Din software bygges ikke i GitHub Actions. GitLab CI og Jenkins er på roadmappen.
• Din eksponering er primært infrastruktur: servere, endpoints og cloud-konfiguration. Værktøjer til sårbarhedsstyring af infrastruktur passer bedre.
• Du integrerer firmware fra tredjeparter, som du ikke selv bygger. Værktøjer til binæranalyse passer bedre.
• Din backlog består mest af ægte, udnyttelige fund i din egen kode. Det er et problem med kapacitet til afhjælpning, ikke et automatiseringsproblem.

Automatisering af sårbarhedsstyring: ofte stillede spørgsmål

Hvorfor er der så mange flere CVE'er nu?

Flere organisationer tildeler CVE'er, og nogle tildeler dem bredt: Linux-kernen blev CVE Numbering Authority i 2024 og tildeler en CVE til enhver fejlrettelse, der kan være en sårbarhed. AI-assisterede værktøjer finder flere fejl pr. forsker. Der blev offentliggjort 47.801 poster i 2025, og 2026 ligger på 303 om dagen. Tendensen har stået på i årevis.

Hvordan kan et lille team følge med i nye CVE'er?

Ved ikke at læse dem. Generér en SBOM for hvert build, match automatisk nye CVE'er mod hver gemt SBOM, skær støjen væk, og lad mennesker kun træffe beslutningerne om det, der er tilbage. Et lille team følger med ved at fjerne de trin, der gentages for hver CVE, ikke ved at arbejde hurtigere.

Hvad skal vi automatisere først i sårbarhedsstyringen?

Inventaret: en SBOM genereret i CI for hvert release-build og gemt sammen med releasen. Alle senere trin afhænger af det, og det gør "er vi berørt?" fra et spørgsmål til udviklingsafdelingen til et opslag. Løbende matchning mod de SBOM'er kommer som nummer to.

Har vi brug for et sikkerhedsteam til at håndtere sårbarheder?

Ikke til at starte med. Én person, der ejer processen på deltid, kan drive den, hvis inventaret, matchningen og støjreduktionen er automatiseret. Du har mere brug for en navngiven ejer og frister end for et team. Ansæt, når arbejdet bliver at rette din egen kode eller sikkerhedsarbejde over for kunder.

Hvordan ved vi, hvilke nye CVE'er der berører vores produkt?

Gem en SBOM for hver leveret version, og tjek dem alle igen, hver gang der offentliggøres nye CVE'er, mod mere end én sårbarhedskilde. En CVE berører dig, når den matcher en komponent og version, du faktisk leverer. Kontekst om udnyttelighed og VEX fortæller derefter, om det betyder noget.

Hvad betyder "maskinlæsbar" for SBOM'er, VEX og advisories, og hvorfor er det vigtigt?

Det betyder et struktureret standardformat, som et værktøj kan parse: CycloneDX eller SPDX for SBOM'er, VEX for erklæringer om ikke berørt, CSAF for advisories. En kundes scanner kan matche dem mod sit inventar, uden at nogen læser dem, så en beslutning, du træffer én gang, genbruges af alle kunder og værktøjer.

Hvor meget af triagen kan automatiseres sikkert?

Indsamlingen af fakta: alvorlighed, om den bliver udnyttet, hvilke produkter og versioner der indeholder komponenten, ejeren, en foreslået prioritet og en frist. Selve beslutningen bør blive hos et menneske. Luk aldrig automatisk et fund som ikke berørt uden en registreret begrundelse.

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

Mindre, end de fleste processer går ud fra. Mandiants M-Trends 2026 anslår den gennemsnitlige tid til udnyttelse i 2025 til minus syv dage, altså udnyttelse, før der findes en patch. Under EU's Cyber Resilience Act kræver en aktivt udnyttet sårbarhed en tidlig advarsel inden for 24 timer. Sæt din egen frist efter alvorlighed og udnyttelse, og mål mod den.