Så hanterar du växande CVE-volymer när teamet är litet

Vad som har förändrats: CVE-siffrorna

Siffrorna nedan kommer från CVE-programmets egna poster och byggs om varje dag på vår sida Trender i CVE-publicering. Enligt ögonblicksbilden från 12 nov. 2026 UTC:

• 47 801 poster publicerades 2025, 20 % fler än året innan.
• 95 494 poster har publicerats hittills 2026, 303 om dagen, +131 % jämfört med den dagliga takten 2025.
• 155 om dagen klassas som höga eller kritiska.
• 17 % av alla poster sedan 2020 saknar CVSS-poäng, både från den som tilldelade posten och från CISA:s berikning. Täckningen har förbättrats: 2026 är andelen 6 %.
• 505 organisationer tilldelade de här posterna, och de 20 största står för 75 % av dem.

• Hög eller kritisk
• Övriga allvarlighetsgrader och utan poäng

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

Dagligt genomsnitt av publicerade poster per år; * markerar innevarande år hittills. Källa: CVE-programmets cvelistV5-poster, ögonblicksbild 12 nov. 2026 UTC. Filter per månad, allvarlighetsgrad och tilldelare: Trender i CVE-publicering.

Det här är inte ett dåligt kvartal. Antalet har ökat varje år sedan 2020, och flera strukturella förändringar håller det uppe:

• Fler tilldelare, som tilldelar bredare. Linuxkärnans projekt blev CVE Numbering Authority i februari 2024. Enligt dess dokumenterade policy tilldelas en CVE till varje buggfix som kan vara en sårbarhet när fixen når en stabil kärna, eftersom det ofta är oklart om något går att utnyttja när fixen landar. Enbart kärnans CNA har publicerat 18 221 poster sedan dess.
• AI-assisterad upptäckt. I november 2024 rapporterade Googles Project Zero och DeepMind att deras agent Big Sleep hade hittat en utnyttjbar minnessäkerhetsbugg i SQLite innan den nådde en release, vilket de tror var det första publika exemplet på att en AI-agent gjort det i allmänt använd programvara. Sådana verktyg ökar hur mycket en enskild forskare kan hitta.
• NVD hinner inte längre berika allt. Enligt NIST byggde National Vulnerability Database upp en eftersläpning av oberikade CVE:er från början av 2024 och kunde inte beta av den när inflödet fortsatte att öka. I april 2026 gick databasen över till en riskbaserad modell: CVE:er i CISA:s katalog Known Exploited Vulnerabilities och CVE:er i federal eller kritisk programvara berikas först, och resten listas som inte schemalagda för omedelbar berikning. En process som förlitar sig på en enda databas uppgifter om berörda produkter får nu vänta, eller missar.
• Kortare tid att reagera. Mandiant mätte en genomsnittlig tid till utnyttjande på 63 dagar 2018 och 2019. Rapporten M-Trends 2026 uppskattar minus sju dagar för 2025: utnyttjandet börjar nu rutinmässigt innan en patch har släppts.
• Regulatoriska klockor. Enligt EU:s Cyber Resilience Act ska tillverkare rapportera en aktivt utnyttjad sårbarhet med en tidig varning inom 24 timmar, en anmälan inom 72 timmar och en slutrapport inom 14 dagar efter att en åtgärd finns tillgänglig (vad CRA kräver). Klockan är densamma för ett team på tre personer som för ett på trehundra.

Inget av detta betyder att programvara blir mindre säker. Det betyder att mängden saker ett team måste titta på växer varje år, medan teamet inte gör det.

Vad som går sönder i ett litet teams process

Växande volymer får inte sårbarhetshanteringen att braka ihop för att det finns fler sårbarheter att åtgärda. De får den att braka ihop för att varje manuellt steg upprepas för varje CVE.

Manuellt steg	Varför det fallerar med dagens volymer
Bygga inventeringen för hand	Ett kalkylark, eller en SBOM som tas fram inför en revision, är inaktuell dagen efter nästa release.
Läsa flödet	Med 155 höga eller kritiska poster om dagen hänger ingen med.
Fråga utvecklingen ”använder vi X?”	Samma fråga för varje CVE, till samma upptagna personer. Frågan är flaskhalsen.
Ett ärende per CVE och repo	En delad biblioteks-CVE blir dussintals dubblettärenden som dränker backloggen.
Svara varje kund en och en	Förfrågningarna växer med kundbasen, inte med antalet sårbarheter.
Dokument i PDF eller på en wiki	Kundernas verktyg kan inte matcha en PDF mot sin inventering, så varje läsare frågar igen.
Tidsgränser som inte flyttar sig	Tiden till utnyttjande krymper medan en manuell process blir långsammare när volymen växer.

Inventeringen. De flesta team som för en komponentlista för hand uppdaterar den inför en revision eller ett kundformulär. Mellan de tillfällena beskriver den programvara som inte längre levereras. Varje CVE-fråga börjar då med att återskapa vad releasen innehöll.

Flödet. Att läsa säkerhetsmeddelanden är steget team börjar med, och det första som kollapsar. Vi hör från team som fortfarande gör det för hand, bland annat ett där sårbarhetsskanning betyder att människor läser CVE-forum. Det fungerar fram till den dag det inte gör det, och det finns ingen signal för den dagen.

Frågan till utvecklingen. ”Använder vi det här biblioteket, och vilken version?” avbryter en utvecklare för varje CVE som kan vara relevant. Ett produktsäkerhetsteam på två personer berättade att arbetet är knapptryckande bara för att hänga med, utan tid kvar att förbättra processen.

Ärendena. När ett delat bibliotek har en CVE och varje repo öppnar ett eget ärende räknar backloggen samma beslut många gånger. Team lär sig att ignorera backloggen och missar sedan ärendet som spelade roll.

Kundsvaren. Efter en mycket uppmärksammad sårbarhet eller en attack mot leveranskedjan frågar kunderna ”är vi berörda?”. Att svara var och en separat kostar mest tid den dag det finns minst av den.

Dokumenten. Ett uttalande i PDF eller en wikisida måste läsas av en människa hos kunden. Kundernas skannrar, och i allt högre grad tillsynsmyndigheter, förväntar sig SBOM:er, VEX och säkerhetsmeddelanden i format som en maskin kan matcha.

Tidsgränserna. En tidig varning som ska lämnas inom 24 timmar, eller en exploit som dyker upp före patchen, väntar inte på att kön ska betas av.

Vad du ska automatisera, i ordning

Varje steg tar bort arbete från nästa, så ordningen spelar större roll än valet av verktyg.

1. Vet vad du levererar. En SBOM från varje bygge gör ”är vi berörda?” till en uppslagning.
2. Matcha kontinuerligt, mot mer än en källa. Nya CVE:er kontrolleras mot varje lagrad SBOM, så ingen behöver läsa flödet.
3. Skär bort bruset. Fynd för sådant du inte levererar, och dubbletter, når aldrig en människa.
4. Triagera halvautomatiskt. Fakta fylls i; en människa fattar beslutet.
5. Gör allt maskinläsbart. Varje beslut fattas en gång och återanvänds av alla läsare.
6. Svara en gång, publikt. Förfrågan som aldrig kommer kostar ingenting.

1. Generera en SBOM för varje bygge, automatiskt

Vad det ersätter: kalkylarket, och frågan till utvecklingen. En SBOM som genereras vid bygget beskriver vad bygget faktiskt använde, och om du sparar en per levererad version kan du svara för förra årets release lika väl som för main. Kunder kör gamla versioner; din inventering måste täcka dem.

Miniminivå: en SBOM som genereras i CI för varje releasebygge och lagras bredvid releaseartefakten. Bättre: en SBOM som registreras från själva bygget i stället för att härledas från lockfiler i efterhand, så att komponenter som hämtas utanför pakethanteraren också kommer med (SBOM:er från bygget, SBOM-automatisering).

Kostnad: en dag eller två av pipelinearbete för miniminivån, sedan ingenting per release. Signal på att det fungerar: för varje release kan du lista dess komponenter utan att fråga någon.

2. Matcha kontinuerligt mot flera sårbarhetskällor

Vad det ersätter: att läsa flödet. Matchning är ett jobb för en maskin: varje ny CVE mot varje lagrad SBOM, inte bara SBOM:en från bygget som just kördes. En gammal release som var ren när den levererades blir berörd den dag en CVE publiceras för en av dess komponenter.

En källa räcker inte. NVD:s eftersläpning i berikningen gör att uppgifter om berörda produkter kan komma sent eller inte alls. Ekosystemens säkerhetsmeddelanden, som GitHub Advisory Database och OSV, är ofta snabbare och anger vilka paketversioner som berörs i ekosystemets egna termer. ENISA:s EU Vulnerability Database tillför EU-sammanhang.

Miniminivå: ett schemalagt jobb som skannar om varje lagrad SBOM dagligen mot en aggregerad källa och rapporterar nya träffar. Signal på att det fungerar: du får veta att en release är berörd innan en kund berättar det. Se sårbarhetsbevakning för hur det ser ut i CRACI.

3. Skär bort bruset innan någon tittar

Vad det ersätter: manuell granskning av fynd som inte spelar någon roll. Det mesta bruset uppstår tidigare i kedjan: i inventeringar som listar sådant du inte levererar, när flera verktyg rapporterar samma CVE och i beroenden som ingen behöver. Rätta inventeringen, räkna varje fynd en gång per paket-URL (PURL), version och CVE, leverera färre beroenden och lägg sedan till sammanhang om utnyttjande från CISA KEV, EPSS och VEX. Så minskar du sårbarhetsbruset går igenom de här spakarna en i taget. Signal på att det fungerar: antalet fynd per levererad release sjunker, och skälen finns dokumenterade.

4. Triagera halvautomatiskt

Vad det ersätter: en människa som samlar fakta för varje fynd. Dela upp arbetet noggrant:

• Automatiskt: allvarlighetsgrad, om den är känd för att utnyttjas, vilka produkter och versioner som innehåller komponenten, det ansvariga teamet, en föreslagen prioritet och ett förfallodatum.
• Mänskligt: beslutet. Åtgärda, mildra, acceptera med ett utgångsdatum eller markera som inte berörd med en motivering.

Det som inte är säkert att automatisera: att stänga ett fynd som inte berört utan ett dokumenterat skäl. Det är undertryckning, och det kommer tillbaka vid en revision eller en incident. Regler för rangordning finns i prioritering av sårbarheter.

Miniminivå: 15 minuter om dagen över en kö som redan är sorterad och ifylld. Signal på att det fungerar: varje beslut har ett dokumenterat skäl, och inget väntar på att någon ska slå upp något.

5. Gör allt maskinläsbart

Vad det ersätter: PDF:er, wikisidor och mejl som en människa måste läsa. Publicera SBOM:er i CycloneDX eller SPDX (CycloneDX vs SPDX), beslut om att inte vara berörd som VEX och säkerhetsmeddelanden i CSAF. Kundernas skannrar och tillsynsmyndigheter kan då använda dem utan en människa, så varje beslut fattas en gång och återanvänds av alla som frågar.

Miniminivå för ett litet team: SBOM:er och VEX på begäran, från en stabil plats; CSAF när kunderna börjar fråga efter det. Signal på att det fungerar: kundernas verktyg slutar flagga det du redan har besvarat.

6. Svara en gång, publikt

Vad det ersätter: en mejltråd per kund. Publicera ett säkerhetsmeddelande eller en statussida för varje betydande CVE, med berörda och åtgärdade versioner, och ha en svarsmall som länkar till den. Guiden om hur du svarar på ”är vi berörda av den här CVE:n?” visar hur du tar fram svaret. För själva svaret har hur du svarar kunder efter en attack mot leveranskedjan svarsmallar. Den billigaste förfrågan är den som aldrig kommer. Signal på att det fungerar: de flesta förfrågningar besvaras med en länk.

Åtgärda sedan

Automatiska pull requests för beroendeuppdateringar håller rutinarbetet igång; samla dem per vecka eller per release så att granskningen förblir hanterbar. Att uppgradera ett paket uppströms rensar ofta flera sårbara transitiva beroenden på en gång, och är billigare än att patcha vart och ett (automatiserad åtgärd av sårbarheter). Stoppa sedan nya kända dåliga komponenter från att komma tillbaka med policygrindar som blockerar bygget.

En plan efter teamstorlek

Timmarna är illustrativa uppskattningar för planering, inte riktmärken.

	En person, deltid	En säkerhets- eller PSIRT-funktion på 2 till 5 personer	Ett större team
Automatisera först	Steg 1 och 2: en SBOM per bygge och kontinuerlig matchning	Steg 1 till 3, sedan fördelning till ansvariga i steg 4	Alla sex, med policygrindar i varje pipeline
Förblir manuellt	Beslutet om varje högt eller kritiskt fynd; kundsvar från en mall	Beslut, VEX-motiveringar, säkerhetsmeddelanden för betydande CVE:er	Beslut, undantag och själva processen
Tid per vecka, illustrativt	2 till 4 timmar	4 till 8 timmar per person	Styrs av beslutsvolymen, inte av flödet

Om du redan har ett PSIRT gäller samma ordning; hela processmodellen finns i livscykeln för sårbarhetshantering. För kundförfrågningarna som blir fler med varje CVE, se skala upp ett PSIRT.

Så vet du att det fungerar

• Tid från CVE-publicering till ”berörd” eller ”inte berörd”, per produkt.
• Andelen kundförfrågningar som besvaras med publicerat material.
• Fynd per levererad release, inte per skanning.
• Andelen beslut med ett dokumenterat skäl.
• Timmar per vecka som läggs på sårbarhetsarbete, och om de minskar.

Mät din egen utgångsnivå först. Det finns inga tillförlitliga branschriktmärken för de här måtten, och vi citerar inga.

Anställa, köpa eller ändra processen?

• Anställ när arbetet består i att åtgärda sårbarheter i din egen kod, eller i kundnära säkerhetsarbete som kräver omdöme.
• Köp verktyg för stegen som upprepas för varje CVE: steg 1, 2, 3 och 5.
• Ändra processen för ansvar och tidsgränser: vem som beslutar, och när.

Var ärlig om det sista. Ett verktyg utan ansvarig producerar en dashboard som ingen läser.

Var CRACI passar in

CRACI automatiserar steg 1 och 2, och delar av steg 3 och 4, för programvara som byggs i GitHub Actions. Det ersätter dina GitHub-hostade runners, och medan varje jobb körs registrerar det paketen som jobbet faktiskt drog in, inklusive paket som återställs från CI-cachar och dolda beroenden som ingen lockfile listar.

• En SBOM från varje bygge. Varje jobbs SBOM identifierar varje komponent med PURL och har en fullständighetsstatus, så att du vet när något inte kunde ses. Bygghistoriken sparar varje tidigare bygge med dess SBOM, så att du kan se vilka byggen som innehöll ett sårbart beroende, direkt eller transitivt.
• Kontinuerlig matchning. Bevakade SBOM:er utvärderas om kontinuerligt, och fynden sammanställs över byggen och repon, så att en CVE i ett delat bibliotek visas som ett problem, inte fyrtio.
• Notifieringar och grindar. CRACI meddelar berörda personer om en sårbarhet och dess allvarlighetsgrad, och policygrindar kan stoppa ett bygge i realtid, även ett bygge som innehåller en specifik CVE.
• Triage och tilldelning. Säkerhetsteam triagerar fynd i CRACI och skickar varje fynd till teamet som äger åtgärden.
• Maskinläsbara SBOM:er. SBOM:er exporteras som CycloneDX eller SPDX, och CRACI har stöd för VEX.

CRACI publicerar inte säkerhetsmeddelanden, erbjuder inte nåbarhetsanalys och skannar inte din egen kod. Det tar bara betalt för byggminuter: $0.002 per vCPU-minut ($0.004 för en standardrunner med 2 vCPU), mätt per sekund, utan månadsavgift, utan avgift per SBOM och utan licensavgift i nuläget. Se priser.

Automatisera de två första stegen i dag: kör dina byggen på CRACI. Vi onboardar varje team personligen innan produkten blir allmänt tillgänglig.

När CRACI inte är svaret

• Din programvara byggs inte i GitHub Actions. GitLab CI och Jenkins finns på roadmapen.
• Din exponering är främst infrastruktur: servrar, ändpunkter och molnkonfiguration. Verktyg för sårbarhetshantering av infrastruktur passar bättre.
• Du integrerar firmware från tredje part som du inte bygger. Verktyg för binäranalys passar bättre.
• Din backlog består mest av verkliga, utnyttjbara fynd i din egen kod. Det är ett problem med kapaciteten att åtgärda, inte ett automatiseringsproblem.

Automatisering av sårbarhetshantering: vanliga frågor

Varför finns det så många fler CVE:er nu?

Fler organisationer tilldelar CVE:er, och vissa tilldelar brett: Linuxkärnan blev CVE Numbering Authority 2024 och tilldelar en CVE till varje buggfix som kan vara en sårbarhet. AI-assisterade verktyg hittar fler buggar per forskare. 47 801 poster publicerades 2025, och 2026 ligger på 303 om dagen. Trenden har pågått i flera år.

Hur kan ett litet team hänga med i nya CVE:er?

Genom att inte läsa dem. Generera en SBOM för varje bygge, matcha nya CVE:er automatiskt mot varje lagrad SBOM, skär bort bruset och låt människor fatta bara besluten om det som återstår. Ett litet team hänger med genom att ta bort stegen som upprepas för varje CVE, inte genom att arbeta snabbare.

Vad ska vi automatisera först i sårbarhetshanteringen?

Inventeringen: en SBOM som genereras i CI för varje releasebygge och lagras med releasen. Varje senare steg bygger på den, och den gör ”är vi berörda?” från en fråga till utvecklingen till en uppslagning. Kontinuerlig matchning mot de SBOM:erna kommer i andra hand.

Behöver vi ett säkerhetsteam för att hantera sårbarheter?

Inte för att börja. En person som äger processen på deltid kan driva den om inventeringen, matchningen och brusreduceringen är automatiserade. Du behöver en namngiven ansvarig och tidsgränser mer än ett team. Anställ när arbetet blir att åtgärda din egen kod eller kundnära säkerhetsarbete.

Hur vet vi vilka nya CVE:er som påverkar vår produkt?

Spara en SBOM för varje levererad version och kontrollera om alla när nya CVE:er publiceras, mot mer än en sårbarhetskälla. En CVE påverkar dig när den matchar en komponent och version som du faktiskt levererar. Sammanhang om utnyttjande och VEX avgör sedan om den spelar roll.

Vad betyder ”maskinläsbar” för SBOM:er, VEX och säkerhetsmeddelanden, och varför spelar det roll?

Det betyder ett standardiserat, strukturerat format som ett verktyg kan tolka: CycloneDX eller SPDX för SBOM:er, VEX för uttalanden om att inte vara berörd, CSAF för säkerhetsmeddelanden. En kunds skanner kan matcha dem mot sin inventering utan att någon läser dem, så ett beslut du fattar en gång återanvänds av alla kunder och verktyg.

Hur mycket av triagen kan automatiseras på ett säkert sätt?

Insamlingen av fakta: allvarlighetsgrad, status för utnyttjande, vilka produkter och versioner som innehåller komponenten, den ansvarige, en föreslagen prioritet och ett förfallodatum. Själva beslutet bör ligga hos en människa. Stäng aldrig ett fynd som inte berört automatiskt utan ett dokumenterat skäl.

Hur lång tid har vi på oss att reagera på en kritisk CVE?

Kortare än de flesta processer antar. Mandiants M-Trends 2026 uppskattar den genomsnittliga tiden till utnyttjande 2025 till minus sju dagar, alltså utnyttjande innan en patch finns. Enligt EU:s Cyber Resilience Act kräver en aktivt utnyttjad sårbarhet en tidig varning inom 24 timmar. Sätt din egen tidsgräns efter allvarlighetsgrad och utnyttjande, och mät mot den.