Hoe u stijgende CVE-aantallen bijhoudt met een klein team

Wat er is veranderd: de CVE-cijfers

De cijfers hieronder komen uit de eigen records van het CVE Program en worden elke dag opnieuw opgebouwd op onze pagina trends in CVE-publicaties. Volgens de momentopname van 12 nov 2026 UTC:

• 47.801 records zijn gepubliceerd in 2025, 20% meer dan het jaar daarvoor.
• 95.494 records zijn tot nu toe gepubliceerd in 2026, 303 per dag, +131% ten opzichte van het dagtempo van 2025.
• 155 per dag hebben de ernst Hoog of Kritiek.
• 17% van alle records sinds 2020 hebben geen CVSS-score, niet van de toewijzer en niet uit de verrijking van CISA. De dekking is verbeterd: in 2026 is het aandeel 6%.
• 505 organisaties hebben deze records toegewezen, en de 20 grootste zijn goed voor 75% ervan.

• Hoog of Kritiek
• Andere ernstniveaus en zonder score

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

Daggemiddelde van de records die in elk jaar zijn gepubliceerd; * markeert het lopende jaar tot nu toe. Bron: de cvelistV5-records van het CVE Program, momentopname 12 nov 2026 UTC. Filters op maand, ernst en toewijzer: trends in CVE-publicaties.

Dit is geen slecht kwartaal. Het aantal is sinds 2020 elk jaar gestegen, en verschillende structurele veranderingen houden die stijging in stand:

• Meer toewijzers, die ruimer toewijzen. Het Linux-kernelproject werd in februari 2024 een CVE Numbering Authority. Volgens zijn gedocumenteerde beleid krijgt elke bugfix die een kwetsbaarheid zou kunnen zijn een CVE zodra de fix een stabiele kernel bereikt, omdat vaak niet duidelijk is of een bug misbruikt kan worden wanneer de fix binnenkomt. De kernel-CNA alleen heeft sindsdien 18.221 records gepubliceerd.
• Door AI ondersteunde ontdekking. In november 2024 meldden Project Zero van Google en DeepMind dat hun agent Big Sleep een misbruikbare geheugenveiligheidsbug in SQLite had gevonden voordat die in een release terechtkwam. Volgens hen was dat het eerste publieke voorbeeld van een AI-agent die dat deed in veelgebruikte software. Tools als deze vergroten hoeveel één onderzoeker kan vinden.
• De NVD kan niet meer alles verrijken. Volgens NIST bouwde de National Vulnerability Database vanaf begin 2024 een achterstand op van niet-verrijkte CVE's, die niet kon worden weggewerkt omdat het aantal inzendingen bleef stijgen. In april 2026 stapte de NVD over op een risicogebaseerd model: CVE's in de Known Exploited Vulnerabilities-catalogus van CISA en CVE's in federale of kritieke software worden eerst verrijkt, en de rest wordt vermeld als niet ingepland voor directe verrijking. Een proces dat leunt op de gegevens over getroffen producten uit één database, wacht nu, of mist iets.
• Minder tijd om te reageren. Mandiant mat in 2018 en 2019 een gemiddelde time to exploit van 63 dagen. Het rapport M-Trends 2026 schat die voor 2025 op min zeven dagen: misbruik begint nu regelmatig voordat er een patch is uitgebracht.
• Wettelijke termijnen. Onder de EU Cyber Resilience Act melden fabrikanten een actief misbruikte kwetsbaarheid met een vroegtijdige waarschuwing binnen 24 uur, een kennisgeving binnen 72 uur en een eindrapport binnen 14 dagen nadat een fix beschikbaar is (wat de CRA vereist). De klok tikt even snel voor een team van drie als voor een team van driehonderd.

Niets hiervan betekent dat software minder veilig wordt. Het betekent dat het aantal dingen waar een team naar moet kijken elk jaar groeit, terwijl het team niet meegroeit.

Wat er misgaat in het proces van een klein team

Stijgende aantallen breken kwetsbaarheidsbeheer niet omdat er meer kwetsbaarheden te repareren zijn. Ze breken het omdat elke handmatige stap zich voor elke CVE herhaalt.

Handmatige stap	Waarom die faalt bij het huidige volume
De inventaris met de hand opbouwen	Een spreadsheet, of een SBOM die vlak voor een audit is gemaakt, is de dag na de volgende release al verouderd.
De feed lezen	Bij 155 records per dag met de ernst Hoog of Kritiek houdt niemand het bij.
Engineering vragen "gebruiken we X?"	Dezelfde vraag voor elke CVE, aan dezelfde drukbezette mensen. De vraag zelf is het knelpunt.
Eén ticket per CVE per repository	De CVE van een gedeelde library wordt tientallen dubbele tickets die de backlog overspoelen.
Elke klant afzonderlijk antwoorden	Vragen groeien mee met het klantenbestand, niet met het aantal kwetsbaarheden.
Documenten in pdf of een wiki	De tools van klanten kunnen een pdf niet met hun inventaris matchen, dus elke lezer vraagt het opnieuw.
Termijnen die niet meebewegen	De time to exploit krimpt, terwijl een handmatig proces trager wordt naarmate het volume groeit.

De inventaris. De meeste teams die een componentenlijst met de hand bijhouden, werken die bij vóór een audit of een vragenlijst van een klant. Tussen die momenten beschrijft de lijst software die niet meer wordt geleverd. Elke CVE-vraag begint dan met reconstrueren wat er in de release zat.

De feed. Advisories lezen is de stap waarmee teams beginnen, en de eerste die bezwijkt. We horen van teams die het nog steeds met de hand doen, waaronder een team waar kwetsbaarheidsscans betekenen dat mensen CVE-forums lezen. Het werkt tot de dag dat het niet meer werkt, en voor die dag bestaat geen signaal.

De vraag aan engineering. "Gebruiken we deze library, en welke versie?" onderbreekt een developer voor elke CVE die van toepassing zou kunnen zijn. Een productbeveiligingsteam van twee mensen vertelde ons dat het werk neerkomt op knoppen drukken om bij te blijven, zonder tijd om het proces te verbeteren.

De tickets. Als een gedeelde library een CVE heeft en elke repository een eigen ticket opent, telt de backlog dezelfde beslissing vele keren. Teams leren de backlog te negeren, en missen dan het ticket dat ertoe deed.

De antwoorden aan klanten. Na een breed uitgemeten kwetsbaarheid of supply chain-aanval vragen klanten "zijn wij getroffen?". Elke klant afzonderlijk antwoorden kost de meeste tijd op de dag dat die het schaarst is.

De documenten. Een verklaring in pdf of een wikipagina moet aan de kant van de klant door een mens worden gelezen. De scanners van klanten, en steeds vaker toezichthouders, verwachten SBOM's, VEX en advisories in formaten die een machine kan matchen.

De termijnen. Een vroegtijdige waarschuwing die binnen 24 uur moet, of een exploit die vóór de patch verschijnt, wacht niet tot de wachtrij leeg is.

Wat u automatiseert, op volgorde

Elke stap haalt werk weg bij de volgende, dus de volgorde doet er meer toe dan de keuze van tools.

1. Weet wat u levert. Een SBOM van elke build maakt van "zijn wij getroffen?" een opzoekactie.
2. Match doorlopend, tegen meer dan één bron. Nieuwe CVE's worden tegen elke opgeslagen SBOM gecontroleerd, dus niemand leest de feed.
3. Verminder de ruis. Bevindingen voor dingen die u niet levert, en duplicaten, bereiken nooit een mens.
4. Triage halfautomatisch. De feiten worden ingevuld; een mens neemt de beslissing.
5. Maak alles machineleesbaar. Elke beslissing wordt één keer genomen en door elke lezer hergebruikt.
6. Antwoord één keer, openbaar. De vraag die nooit binnenkomt, kost niets.

1. Genereer automatisch een SBOM voor elke build

Wat het vervangt: de spreadsheet, en de vraag aan engineering. Een SBOM die tijdens de build wordt gegenereerd, beschrijft wat de build daadwerkelijk heeft gebruikt, en met één SBOM per geleverde versie kunt u antwoorden voor de release van vorig jaar en niet alleen voor main. Klanten draaien oude versies; uw inventaris moet die ook dekken.

Minimale versie: een SBOM die in CI wordt gegenereerd voor elke releasebuild en naast het releaseartefact wordt opgeslagen. Beter: een SBOM die wordt vastgelegd uit de build zelf in plaats van achteraf afgeleid uit lockfiles, zodat ook componenten die buiten de pakketbeheerder om zijn opgehaald erin staan (build-time SBOM's, SBOM-automatisering).

Kosten: een dag of twee pipelinewerk voor de minimale versie, daarna niets per release. Signaal dat het werkt: voor elke release kunt u de componenten opsommen zonder iemand iets te vragen.

2. Match doorlopend tegen meerdere kwetsbaarheidsbronnen

Wat het vervangt: de feed lezen. Matchen is werk voor een machine: elke nieuwe CVE tegen elke opgeslagen SBOM, niet alleen tegen de SBOM van de build die net is gedraaid. Een oude release die schoon was toen hij werd geleverd, is getroffen op de dag dat er een CVE verschijnt voor een van zijn componenten.

Eén bron is niet genoeg. Door de verrijkingsachterstand van de NVD kunnen gegevens over getroffen producten laat of helemaal niet komen. Advisories uit de ecosystemen zelf, zoals de GitHub Advisory Database en OSV, zijn vaak sneller en zeggen in de termen van het ecosysteem welke pakketversies getroffen zijn. De EU Vulnerability Database van ENISA voegt Europese context toe.

Minimale versie: een geplande job die elke opgeslagen SBOM dagelijks opnieuw scant tegen een geaggregeerde bron en nieuwe matches meldt. Signaal dat het werkt: u weet dat een release getroffen is voordat een klant het u vertelt. Zie kwetsbaarheden volgen voor hoe dit eruitziet in CRACI.

3. Verminder de ruis voordat iemand kijkt

Wat het vervangt: handmatige beoordeling van bevindingen die er niet toe doen. De meeste ruis ontstaat eerder in de keten: door inventarissen die dingen vermelden die u niet levert, door meerdere tools die dezelfde CVE melden, en door afhankelijkheden die niemand nodig heeft. Corrigeer de inventaris, tel elke bevinding één keer op package URL (PURL), versie en CVE, lever minder afhankelijkheden, en voeg daarna context over misbruikbaarheid toe uit CISA KEV, EPSS en VEX. Kwetsbaarheidsruis verminderen behandelt deze hefbomen één voor één. Signaal dat het werkt: het aantal bevindingen per geleverde release daalt, en de redenen zijn vastgelegd.

4. Triage halfautomatisch

Wat het vervangt: een mens die voor elke bevinding de feiten verzamelt. Verdeel het werk precies:

• Automatisch: de ernst, of bekend is dat de kwetsbaarheid wordt misbruikt, welke producten en versies het component bevatten, het verantwoordelijke team, een voorgestelde prioriteit en een deadline.
• Mens: de beslissing. Repareren, mitigeren, accepteren met een vervaldatum, of markeren als niet getroffen met een onderbouwing.

Wat niet veilig te automatiseren is: een bevinding sluiten als niet getroffen zonder vastgelegde reden. Dat is onderdrukken, en het komt terug bij een audit of een incident. Regels voor de rangschikking staan in kwetsbaarheden prioriteren.

Minimale versie: 15 minuten per dag met een wachtrij die al gesorteerd en ingevuld is. Signaal dat het werkt: elke beslissing heeft een vastgelegde reden, en niets wacht tot iemand iets heeft opgezocht.

5. Maak alles machineleesbaar

Wat het vervangt: pdf's, wikipagina's en e-mails die een mens moet lezen. Publiceer SBOM's in CycloneDX of SPDX (CycloneDX vs SPDX), beslissingen over niet-getroffen zijn als VEX, en advisories in CSAF. De scanners van klanten en toezichthouders kunnen ze dan zonder tussenkomst van een mens verwerken, zodat elke beslissing één keer wordt genomen en wordt hergebruikt door iedereen die ernaar vraagt.

Minimale versie voor een klein team: SBOM's en VEX op verzoek, vanaf een vaste locatie; CSAF zodra klanten erom gaan vragen. Signaal dat het werkt: de tools van klanten markeren niet langer wat u al hebt beantwoord.

6. Antwoord één keer, openbaar

Wat het vervangt: één e-mailthread per klant. Publiceer voor elke significante CVE een advisory of statuspagina met de getroffen en gerepareerde versies, en houd een antwoordsjabloon bij dat ernaar linkt. De gids "Zijn wij getroffen door deze CVE?" beantwoorden laat zien hoe u tot het antwoord komt. Voor het antwoord zelf bevat hoe u klanten antwoordt na een aanval op de softwareketen antwoordsjablonen. De goedkoopste vraag is de vraag die nooit binnenkomt. Signaal dat het werkt: de meeste vragen worden beantwoord met een link.

Daarna repareren

Geautomatiseerde pull requests voor dependency-updates houden het routinewerk in beweging; bundel ze per week of per release, zodat de review behapbaar blijft. Eén upstreampakket upgraden lost vaak meerdere kwetsbare transitieve afhankelijkheden tegelijk op, en is goedkoper dan elk ervan apart patchen (geautomatiseerd herstel van kwetsbaarheden). Voorkom daarna dat nieuwe bekende slechte componenten terugkomen met policy gates die de build blokkeren.

Een plan per teamgrootte

De uren zijn illustratieve schattingen voor de planning, geen benchmarks.

	Eén persoon, parttime	Een security- of PSIRT-functie van 2 tot 5 mensen	Een groter team
Eerst automatiseren	Stap 1 en 2: een SBOM per build en doorlopende matching	Stap 1 tot en met 3, daarna doorsturen naar eigenaren in stap 4	Alle zes, met policy gates in elke pipeline
Blijft handwerk	De beslissing over elke bevinding met de ernst Hoog of Kritiek; antwoorden aan klanten vanuit een sjabloon	Beslissingen, VEX-onderbouwingen, advisories voor significante CVE's	Beslissingen, uitzonderingen en het proces zelf
Tijd per week, ter illustratie	2 tot 4 uur	4 tot 8 uur per persoon	Bepaald door het aantal beslissingen, niet door de feed

Hebt u al een PSIRT, dan geldt dezelfde volgorde; het volledige procesmodel staat in de levenscyclus van kwetsbaarheidsbeheer. Voor de klantvragen die met elke CVE toenemen, zie een PSIRT opschalen.

Hoe u weet dat het werkt

• De tijd van publicatie van een CVE tot "getroffen" of "niet getroffen", per product.
• Het aandeel klantvragen dat met gepubliceerd materiaal wordt beantwoord.
• Bevindingen per geleverde release, niet per scan.
• Het aandeel beslissingen met een vastgelegde reden.
• Uren per week aan kwetsbaarheidswerk, en of dat aantal daalt.

Meet eerst uw eigen nulmeting. Er bestaan geen betrouwbare benchmarks uit de branche hiervoor, en wij noemen er ook geen.

Iemand aannemen, tooling kopen of het proces veranderen?

• Neem iemand aan als het werk bestaat uit kwetsbaarheden in uw eigen code repareren, of uit beveiligingswerk richting klanten waarvoor oordeelsvermogen nodig is.
• Koop tooling voor de stappen die zich per CVE herhalen: stap 1, 2, 3 en 5.
• Verander het proces voor eigenaarschap en termijnen: wie beslist, en wanneer.

Wees eerlijk over dat laatste. Een tool zonder eigenaar levert een dashboard op dat niemand leest.

Waar CRACI past

CRACI automatiseert stap 1 en 2, en een deel van stap 3 en 4, voor software die in GitHub Actions wordt gebouwd. Het vervangt uw GitHub-hosted runners en legt tijdens elke job de pakketten vast die de job daadwerkelijk heeft binnengehaald, inclusief pakketten die uit CI-caches zijn teruggezet en verborgen afhankelijkheden die in geen enkele lockfile staan.

• Een SBOM van elke build. De SBOM van elke job identificeert elk component met een PURL en heeft een volledigheidsstatus, zodat u weet wanneer iets niet kon worden gezien. De buildgeschiedenis bewaart elke eerdere build met zijn SBOM, zodat u ziet welke builds een kwetsbare afhankelijkheid bevatten, direct of transitief.
• Doorlopende matching. Gemonitorde SBOM's worden doorlopend opnieuw beoordeeld, en bevindingen worden over builds en repositories heen gebundeld, zodat de CVE van een gedeelde library als één probleem verschijnt, niet als veertig.
• Meldingen en gates. CRACI brengt de betrokken mensen op de hoogte van een kwetsbaarheid en de ernst ervan, en policy gates kunnen een build in realtime stoppen, ook een build die een specifieke CVE bevat.
• Triage en toewijzing. Securityteams triëren bevindingen in CRACI en sturen elke bevinding naar het team dat verantwoordelijk is voor de fix.
• Machineleesbare SBOM's. SBOM's worden geëxporteerd als CycloneDX of SPDX, en CRACI ondersteunt VEX.

CRACI publiceert geen advisories, biedt geen reachability-analyse en scant uw eigen code niet. U betaalt alleen voor buildminuten: $0.002 per vCPU-minuut ($0.004 voor een standaardrunner met 2 vCPU's), per seconde gemeten, zonder maandelijkse kosten, zonder kosten per SBOM en op dit moment zonder licentiekosten. Zie prijzen.

Automatiseer de eerste twee stappen vandaag nog: draai uw builds op CRACI. We begeleiden elk team persoonlijk bij de onboarding tot de algemene beschikbaarheid.

Wanneer CRACI niet het antwoord is

• Uw software wordt niet in GitHub Actions gebouwd. GitLab CI en Jenkins staan op de roadmap.
• Uw blootstelling zit vooral in infrastructuur: servers, endpoints en cloudconfiguratie. Tools voor kwetsbaarheidsbeheer van infrastructuur passen dan beter.
• U integreert firmware van derden die u niet zelf bouwt. Tools voor binaire analyse passen dan beter.
• Uw backlog bestaat vooral uit echte, misbruikbare bevindingen in uw eigen code. Dat is een probleem van herstelcapaciteit, geen automatiseringsprobleem.

Kwetsbaarheidsbeheer automatiseren: veelgestelde vragen

Waarom zijn er nu zoveel meer CVE's?

Meer organisaties wijzen CVE's toe, en sommige doen dat ruim: de Linux-kernel werd in 2024 een CVE Numbering Authority en wijst er een toe aan elke bugfix die een kwetsbaarheid zou kunnen zijn. Door AI ondersteunde tools vinden meer bugs per onderzoeker. In 2025 zijn 47.801 records gepubliceerd, en 2026 zit op 303 per dag. De trend loopt al jaren.

Hoe houdt een klein team nieuwe CVE's bij?

Door ze niet te lezen. Genereer een SBOM voor elke build, match nieuwe CVE's automatisch tegen elke opgeslagen SBOM, verminder de ruis en laat mensen alleen beslissen over wat overblijft. Een klein team houdt het bij door de stappen te schrappen die zich voor elke CVE herhalen, niet door sneller te werken.

Wat automatiseren we als eerste in kwetsbaarheidsbeheer?

De inventaris: een SBOM die in CI wordt gegenereerd voor elke releasebuild en bij de release wordt opgeslagen. Elke latere stap hangt ervan af, en het maakt van "zijn wij getroffen?" een opzoekactie in plaats van een vraag aan engineering. Doorlopende matching tegen die SBOM's komt op de tweede plaats.

Hebben we een securityteam nodig om kwetsbaarheden af te handelen?

Niet om te beginnen. Eén persoon die parttime eigenaar is van het proces, kan het draaien als de inventaris, de matching en de ruisreductie geautomatiseerd zijn. U hebt eerder een benoemde eigenaar en termijnen nodig dan een team. Neem iemand aan wanneer het werk verschuift naar het repareren van uw eigen code of beveiligingswerk richting klanten.

Hoe weten we welke nieuwe CVE's ons product raken?

Bewaar een SBOM voor elke geleverde versie en controleer ze allemaal opnieuw zodra nieuwe CVE's worden gepubliceerd, tegen meer dan één kwetsbaarheidsbron. Een CVE raakt u wanneer die overeenkomt met een component en versie die u daadwerkelijk levert. Context over misbruikbaarheid en VEX bepalen vervolgens of het ertoe doet.

Wat betekent "machineleesbaar" voor SBOM's, VEX en advisories, en waarom is het belangrijk?

Het betekent een gestandaardiseerd, gestructureerd formaat dat een tool kan verwerken: CycloneDX of SPDX voor SBOM's, VEX voor verklaringen dat een product niet getroffen is, CSAF voor advisories. De scanner van een klant kan ze met zijn inventaris matchen zonder dat iemand ze leest, zodat een beslissing die u één keer neemt, door elke klant en elke tool wordt hergebruikt.

Hoeveel van de triage kan veilig worden geautomatiseerd?

Het verzamelen van de feiten: ernst, status van misbruik, welke producten en versies het component bevatten, de eigenaar, een voorgestelde prioriteit en een deadline. De beslissing zelf hoort bij een mens te blijven. Sluit een bevinding nooit automatisch als niet getroffen zonder vastgelegde reden.

Hoeveel tijd hebben we om te reageren op een kritieke CVE?

Minder dan de meeste processen aannemen. M-Trends 2026 van Mandiant schat de gemiddelde time to exploit in 2025 op min zeven dagen, wat betekent dat misbruik begint voordat er een patch is. Onder de EU Cyber Resilience Act vraagt een actief misbruikte kwetsbaarheid om een vroegtijdige waarschuwing binnen 24 uur. Stel uw eigen termijn vast op basis van ernst en misbruik, en meet daartegen.