AI Verandert Open-Source-Beveiliging: De Verantwoordelijkheid Voor De Levenscyclus Van Software Moet Daarop Aangepast Worden

Toen Drupal CVE-2026-9082 in mei bekendmaakte, werden binnen 48 uur pogingen tot exploitatie gemeld. Die krimpende tijd tussen bekendmaking en exploitatie illustreert de nieuwe realiteit waarmee organisaties die afhankelijk zijn van open-source-software te maken krijgen. Ze hebben minder tijd dan ooit tevoren om risico’s te beoordelen en te reageren voordat kwetsbaarheden actief worden aangevallen.

AI versnelt die verschuiving door de snelheid en omvang van kwetsbaarheidsontdekking dramatisch te vergroten. Naarmate de ontdekking van kwetsbaarheden versnelt, is de uitdaging voor ondernemingen niet langer alleen het identificeren van kwetsbaarheden; het is ervoor zorgen dat de software waarvan ze afhankelijk zijn, blijft worden beveiligd, ondersteund en veerkrachtig gedurende de hele levenscyclus.

AI Versnelt Bedreigingen Sneller Dan Ondernemingen Kunnen Reageren

AI-gestuurde tools versnellen de ontdekking van kwetsbaarheden en verlagen de drempel voor de ontwikkeling van exploits, waardoor de tijd die organisaties hebben om risico’s te beoordelen en te reageren, wordt verkort. Bijgewerkte industrievoorspellingen van FIRST schatten nu dat bijna 66.000 CVE’s in 2026 zullen worden bekendgemaakt, een revisie van 11% ten opzichte van de prognose van februari, nadat de bekendmakingen in april 46% boven het verwachte tempo uitkwamen.

FIRST merkt terecht op dat het exploiteerbare risico niet in hetzelfde tempo is toegenomen als het brute volume, en dat KEV- en EPSS-triages de golf kunnen opvangen. Maar triage-en-patch veronderstelt dat een patch bestaat. Voor software die is gebouwd op frameworks met einde van het leven, is dat niet het geval, en de hele prioriteringsmodus stort op het moment ineen waarop het het meest van belang is.

Ondertussen opereren beveiligingsteams niet op machinesnelheid. Ze moeten nog steeds bepalen welke systemen zijn aangetast, het bedrijfsrisico beoordelen, fixes testen en updates implementeren zonder de bedrijfsvoering te verstoren. Voor organisaties die afhankelijk zijn van open-source-software, wordt die uitdaging nog groter wanneer bedrijfskritische componenten het einde van hun leven hebben bereikt en geen beveiligingspatches meer ontvangen van hun oorspronkelijke onderhouders.

Het resultaat is een groeiende kloof tussen het identificeren van kwetsbaarheden en het daadwerkelijk herstellen ervan. Organisaties hebben meer nodig dan zichtbaarheid in kwetsbaarheden. Ze hebben vertrouwen nodig dat de software waarvan ze afhankelijk zijn, blijft worden beveiligd en ondersteund gedurende de hele levenscyclus.

Ondersteunde Software Wordt Een Groeiend Bedrijfsrisico

Veel organisaties blijven oude versies van open-source-frameworks zoals Drupal, Spring en AngularJS gebruiken, omdat het vervangen van bedrijfskritische toepassingen duur, verstorend en vaak jaren duurt.

Die realiteit botst steeds vaker met nieuwe regelgevende verwachtingen. Frameworks zoals de EU-Cyber Resilience Act, DORA, NIS2 en PCI DSS 4.0 leggen meer nadruk op softwareonderhoud, zichtbaarheid van de toeleveringsketen en voortdurende softwareondersteuning, waardoor niet-ondersteunde software een groeiend compliance- en operationeel probleem wordt.

Omdat modernisering vaak jaren duurt, hebben organisaties een strategie nodig om beveiligde, ondersteunde software te behouden gedurende de transitie.

Organisaties Hebben Levenscycluszichtbaarheid Nodig, Niet Alleen Kwetsbaarheidszichtbaarheid

De meeste organisaties hebben flink geïnvesteerd in tools die zijn ontworpen om kwetsbaarheden in hun omgeving te identificeren. Die tools beantwoorden de vraag waar de kwetsbaarheden zijn. Ze geven geen antwoord op een andere vraag die even belangrijk wordt: Is deze software nog steeds ondersteund?

Om die vraag te beantwoorden, moeten organisaties verder kijken dan kwetsbaarheidsbeheer. Ze moeten zichtbaarheid hebben in of bedrijfskritische open-source-componenten nog steeds actief worden onderhouden, of dat ze het einde van hun leven naderen of geen communityondersteuning meer ontvangen, en een strategie hebben om die systemen beveiligd te houden totdat modernisering is voltooid.

Bedrijfsleiders moeten zich op drie prioriteiten richten:

• Weet wat je hebt. Ondersteunde software identificeren voordat kwetsbaarheden, audits of incidenten het probleem afdwingen, en begrijpen welke bedrijfskritische toepassingen ervan afhankelijk zijn.
• Plan een beveiligde modernisering. Levenscyclusplanning opnemen in inkoop-, ontwikkelings- en moderniseringsstrategieën, met duidelijke plannen om software op een beveiligde manier te onderhouden gedurende de transitie.
• Behandel softwareondersteuning als een bedrijfsprioriteit. Naarmate software-ecosystemen complexer worden, moet langetermijnondersteuning van software worden behandeld als een strategische bedrijfsvaardigheid en niet alleen als een technisch probleem.

AI verandert de manier waarop software wordt gebouwd, hoe kwetsbaarheden worden ontdekt en hoe snel organisaties worden verwacht te reageren. Wat niet is veranderd, is de verantwoordelijkheid van ondernemingen om de software waarvan ze al afhankelijk zijn, op een beveiligde manier te onderhouden. Naarmate AI de beveiliging van open-source-software verandert, zal succes afhangen van het behandelen van de verantwoordelijkheid voor de levenscyclus van software als een kernbeveiligingscapaciteit, niet alleen als een technische overweging.

De organisaties die slagen, zullen niet noodzakelijkerwijs degene zijn die het snelst patches. Ze zullen degene zijn die softwarerisico’s met vertrouwen kunnen beheren gedurende de hele levenscyclus, door bedrijfskritische toepassingen beveiligd en operationeel te houden, terwijl ze op eigen kracht moderniseren.