Waarom zien we ineens zoveel CVE's?

Steeds vaker verschijnen er berichten over nieuwe kwetsbaarheden in frameworks, libraries, CMS'en, Linux-packages en andere open-source software. Voor organisaties kan dat een ongemakkelijk beeld geven. Als er iedere week nieuwe CVE's (Common Vulnerabilities and Exposures) worden gepubliceerd, wordt software dan steeds onveiliger?

Niet per se.

Wat vooral verandert, is ons vermogen om kwetsbaarheden te vinden. Securityonderzoek wordt verder geautomatiseerd, dependency scanners controleren continu gebruikte softwarecomponenten en AI kan onderzoekers helpen om grotere hoeveelheden code sneller te analyseren. Daardoor worden fouten gevonden die vroeger mogelijk jarenlang onopgemerkt bleven.

Voor Brighteq is een CVE daarom niet automatisch een alarmsignaal. Het is in eerste instantie informatie. Als senior developers en beheerders kijken we vervolgens naar de context: gebruiken we de kwetsbare software daadwerkelijk, draait de getroffen versie binnen een project, is de kwetsbare functionaliteit bereikbaar en kan een aanvaller er in onze configuratie daadwerkelijk misbruik van maken?

Dat onderscheid is belangrijk. Goed vulnerability management draait niet om iedere melding zo snel mogelijk weg te werken. Het draait om weten wat er in je applicatie draait, begrijpen wat het werkelijke risico is en op het juiste moment de juiste technische actie nemen.

AI verandert softwareontwikkeling, maar ook securityonderzoek. Systemen kunnen steeds grotere codebases analyseren, patronen herkennen en developers ondersteunen bij het onderzoeken van potentieel kwetsbare code. OpenSSF (de Open Source Security Foundation) beschrijft AI daarom vooral als een versneller: het tempo waarin kwetsbaarheden worden gevonden, gemeld, onderzocht en opgelost neemt toe.

Daar komt bij dat moderne applicaties uit veel meer bestaan dan alleen de code die een developmentteam zelf schrijft.

Een webapplicatie kan bijvoorbeeld gebruikmaken van een framework zoals Symfony, een CMS zoals Drupal, Wordpress of Magento, tientallen Composer- of npm-packages, een PHP-runtime, database, webserver, Linux-packages en verschillende services. Al deze componenten hebben weer hun eigen versies en afhankelijkheden.

Security tooling kan deze dependency chain steeds beter automatisch controleren. Platforms zoals GitHub en GitLab kunnen gebruikte dependencies vergelijken met databases van bekende kwetsbaarheden en een melding genereren zodra een gebruikte versie kwetsbaar blijkt te zijn. GitLab kan daarbij ook runtime-, development- en indirecte dependencies meenemen.

Dat levert meer meldingen op, maar dat is juist een teken dat de zichtbaarheid verbetert.

De gedachte dat AI ineens grote hoeveelheden nieuwe problemen veroorzaakt, is daarom te simpel. AI helpt kwetsbaarheden sneller bloot te leggen, terwijl betere tooling en een volwassenere securitycommunity hetzelfde doen.

Je kunt het vergelijken met betere medische diagnostiek. Wanneer een onderzoekstechniek beter wordt, worden er meer afwijkingen gevonden. Dat betekent niet automatisch dat die afwijkingen daarvoor niet bestonden.

CVE staat voor Common Vulnerabilities and Exposures. Het CVE-programma is opgezet om publiek bekende securitykwetsbaarheden op een gestandaardiseerde manier te identificeren. Een kwetsbaarheid krijgt een uniek nummer, bijvoorbeeld CVE-2026-12345, zodat leveranciers, developers, securityonderzoekers en tooling allemaal naar hetzelfde probleem kunnen verwijzen.

Een CVE vertelt ons dus welk beveiligingsprobleem is gevonden en welke software of versies mogelijk geraakt worden.

De ernst wordt meestal apart beoordeeld. Daarvoor wordt vaak CVSS, het Common Vulnerability Scoring System, gebruikt. CVSS beschrijft de technische ernst van een kwetsbaarheid en kan resulteren in een score van laag tot kritisch. Belangrijk daarbij is dat CVSS severity meet en niet automatisch het daadwerkelijke risico binnen jouw omgeving.

Dat verschil is essentieel.

Stel dat er een kritieke kwetsbaarheid wordt gevonden in een library die binnen jouw applicatie aanwezig is. Alleen dat gegeven is nog niet voldoende om te bepalen of je applicatie direct gevaar loopt.

Bij Brighteq registreren we onder andere:

• Welke software en versies gebruikt het project?
• Is de getroffen dependency daadwerkelijk geïnstalleerd?
• Wordt de kwetsbare functionaliteit binnen de applicatie gebruikt?
• Is deze functionaliteit vanaf internet bereikbaar?
• Vereist misbruik authenticatie of specifieke rechten?
• Is de kwetsbaarheid door onze configuratie al gemitigeerd?
• Bestaat er een beveiligingsupdate of andere technische maatregel?
• Is bekend dat de kwetsbaarheid in de praktijk actief wordt misbruikt?

Dat laatste is bijvoorbeeld relevant bij kwetsbaarheden die voorkomen in de Known Exploited Vulnerabilities-catalogus van CISA. Deze catalogus bevat kwetsbaarheden waarvoor bewijs bestaat van daadwerkelijke exploitatie en biedt daarmee extra context bij de prioritering van updates.

Een CVE in een package dat nergens door de applicatie wordt aangeroepen, kan daardoor een heel ander risicoprofiel hebben dan exact dezelfde CVE in een publiek bereikbare functionaliteit.

Daarom begint security bij inzicht in je tech stack.

Wanneer binnen een door Brighteq beheerde omgeving een relevante securitymelding binnenkomt, beoordelen we eerst de impact.

Je hoeft dus niet zelf dagelijks CVE-databases te controleren.

We volgen securityfeeds en meldingen rondom de technologie die binnen onze projecten wordt gebruikt. Vervolgens vergelijken we een melding met de daadwerkelijke applicatie en infrastructuur.

Bij een kwetsbaarheid met directe impact kan snel handelen noodzakelijk zijn. Denk bijvoorbeeld aan een kwetsbaarheid die zonder authenticatie vanaf het internet kan worden misbruikt en waarmee een aanvaller code kan uitvoeren of gevoelige gegevens kan benaderen.

Maar andere CVE's gelden alleen onder heel specifieke omstandigheden. Een kwetsbare module kan bijvoorbeeld wel geïnstalleerd zijn, terwijl de betreffende functionaliteit is uitgeschakeld. Of misbruik vereist lokale toegang tot een Linux-server die een externe bezoeker helemaal niet heeft.

Blind patches installeren is daarom ook niet onze aanpak.

Een update kan invloed hebben op andere dependencies, maatwerkcode of koppelingen. Zeker binnen grotere webapplicaties en e-commerceomgevingen wil je weten wat je wijzigt. Afhankelijk van het risico testen we een patch daarom eerst en voeren we deze vervolgens gecontroleerd door.

Onze prioritering bestaat in de praktijk uit een combinatie van technische severity, bereikbaarheid, configuratie, mogelijke impact, beschikbare exploits en de rol van het getroffen systeem.

Een CVSS-score is daarbij waardevolle input, maar nooit het volledige besluit. Ook FIRST, de organisatie achter CVSS, benadrukt expliciet dat een CVSS Base Score severity aangeeft en niet zelfstandig als risicoscore moet worden gebruikt.

Dit is precies waarom vulnerability management specialistisch werk is. Een lijst met twintig meldingen is relatief eenvoudig te genereren. Bepalen welke van die twintig daadwerkelijk aandacht nodig hebben, vraagt kennis van softwarearchitectuur, dependencies, hosting en de specifieke applicatie.

Kun je beveiligingslekken volledig preventief voorkomen? Nee.

Zelfs wanneer je secure coding practices toepast, dependencies actueel houdt, systemen hardent en zorgvuldig test, kan morgen een kwetsbaarheid worden ontdekt in software die vandaag als veilig wordt beschouwd.

Het doel is daarom niet om te garanderen dat er nooit meer een CVE verschijnt. Het doel is om de kans op misbruik te verkleinen en ervoor te zorgen dat je snel weet wanneer actie nodig is.

Bij Brighteq kijken we daarvoor verder dan alleen de applicatiecode. Security loopt door de hele technische stack: van frameworks en packages tot hosting, Linux-configuratie en deployment.

Structureel beheer betekent onder andere dat we weten welke software wordt gebruikt, securitymeldingen volgen, dependencies controleren en kwetsbaarheden technisch beoordelen. Moderne dependency-scanning kan hierbij automatisch bekende kwetsbaarheden signaleren zodra nieuwe advisories beschikbaar komen.

Juist open-source software heeft daarbij een belangrijk voordeel: de broncode kan door een brede community worden onderzocht. Problemen kunnen door onafhankelijke onderzoekers worden gevonden, besproken en opgelost. Dat betekent niet dat ieder open-sourceproject automatisch veilig is. De kwaliteit en het onderhoud verschillen per project. Het betekent wel dat securityproblemen niet uitsluitend afhankelijk zijn van wat één commerciële leverancier intern ontdekt en besluit openbaar te maken.

Meer zichtbare kwetsbaarheden zijn daarom niet automatisch een argument tegen open source.

Sterker nog, zichtbaarheid is een belangrijk onderdeel van volwassen security. Je wilt liever weten dat een kwetsbaarheid bestaat, zodat je kunt beoordelen of je geraakt wordt en een update kunt uitvoeren, dan dat hetzelfde probleem jarenlang onzichtbaar in gesloten software aanwezig blijft.

OpenSSF benadrukt daarbij dat AI de fundamentele securityprincipes niet verandert. Zaken als een beperkt aanvalsoppervlak, minimale rechten, goed vulnerability management en proactieve security engineering blijven bepalend. AI verhoogt vooral de snelheid waarmee zowel aanvallers als verdedigers kunnen werken.

Dat sluit aan op hoe Brighteq naar softwareontwikkeling kijkt.

We bouwen niet alleen een applicatie en leveren die vervolgens op. Een professioneel digitaal platform vraagt gedurende zijn hele levenscyclus om onderhoud, monitoring en technische aandacht. Nieuwe CVE's horen bij die werkelijkheid.

Het relevante securityvraagstuk is daarom niet:

"Heeft onze software kwetsbaarheden?"

Een betere vraag is:

"Weten we welke software we gebruiken, zien we nieuwe kwetsbaarheden op tijd en kunnen we onderbouwd bepalen wanneer actie nodig is?"

Dat is het verschil tussen reageren op securitymeldingen en structureel grip houden op security.