.NET developer, SC-300 Microsoft Security gecertificeerd, werkt dagelijks met AI-agents. Geeft persoonlijk perspectief op de impact van AI op software security.
De packages die je niet durft te updaten
Elk .NET team heeft ze. Die ene NuGet package waar niemand meer aankomt, omdat het de laatste keer drie dagen kostte om alles weer werkend te krijgen. Een Angular frontend met een node_modules boom waar je liever niet in kijkt. Een Docker image die “gewoon werkt” op een base image van jaren geleden.
Je kent het scenario. Iemand update een transitieve dependency. De build breekt. Soms is het een uur. Soms een dag. Soms blokkeer je een hele sprint. En het enige wat je wilde was een minor version bump.
Ondertussen wil je team innoveren. Nieuwe features bouwen. De migratie staat op de backlog, en er is altijd iets urgenters. Tot het moment dat je moet reageren en ontdekt dat je niet kunt.
Dat verandert nu
Claude Mythos vond volgens Anthropic een 27 jaar oude bug in OpenBSD, een 17 jaar oude remote code execution in FreeBSD, en een 16 jaar oude kwetsbaarheid in FFmpeg die 5 miljoen geautomatiseerde scans overleefde. Anthropic rapporteert meer dan 1.000 critical-severity kwetsbaarheden. De Glasswing-partners werken aan patches, maar het patchen kost tijd en de meeste fixes zijn nog niet uitgerold.
Dit model is nog niet publiek, en de claims verdienen kritische lezing (daarover meer verderop). Maar de boodschap is niet dat elk team morgen moet migreren. Het is dat verdedigers zich moeten voorbereiden op een wereld waarin AI-gestuurde aanvallers sneller en systematischer kwetsbaarheden vinden. Voor teams met een goed onderhouden stack is dat een aandachtspunt. Voor teams met legacy is het urgenter.
Het dreigingslandschap versnelt
Hoe hard dit je raakt hangt af van je stack, je exposure en je patch-discipline. De trend is duidelijk: het volume en de snelheid van kwetsbaarheden stijgen.
En het gaat niet alleen om kwetsbaarheden in code. Op 31 maart 2026 compromitteerde een Noord-Koreaanse groep het Axios npm package, een library met 100 miljoen downloads per week. Niet door code te hacken, maar door het account van de maintainer te compromitteren en met een gestolen access token de CI/CD pipeline te omzeilen. Zelfs actief onderhouden open-source packages zijn kwetsbaar.
En bedenk: elke package die je installeert brengt tientallen transitieve dependencies mee, code en maintainers die je niet kent. Een kwetsbaarheid in een package die je nooit bewust hebt geïnstalleerd raakt jouw productie.
Mythos of mythe?
Niet elke kwetsbaarheid die Claude Mythos vindt is exploitable. Tom's Hardware wijst erop dat veel gevonden bugs in oudere software zitten of in de praktijk niet te misbruiken zijn, en dat de “duizenden” kwetsbaarheden rusten op slechts 198 manuele reviews. Beveiligingsonderzoeker Heidy Khlaaf waarschuwt dat we de claims niet zonder meer moeten aannemen zonder informatie over false positive-percentages en hoe die reviews zijn uitgevoerd. De vraag hoeveel van die “duizenden” kwetsbaarheden daadwerkelijk te misbruiken zijn in een productie-omgeving wordt door Anthropic niet beantwoord.
Critici vragen zich ook af of dit een eerlijke waarschuwing is of marketing richting een verwachte beursgang.
Maar ook als je de helft van de claims wegstreept, blijft de richting staan: AI-gestuurde vulnerability scanning wordt beter, sneller en goedkoper. De vraag is niet of de cijfers exact kloppen, maar of je team erop voorbereid is.
Hoe reageert jouw team als het zover is?
Ik kan niet bewijzen dat dit jouw stack morgen raakt. Maar de vraag is niet of je kwetsbaar bent, maar of je snel genoeg kunt reageren als het zover is.
Hoe urgent dat is verschilt per service. Internet-exposed? Hoge privileges? Runtime code of build tooling? Een kritieke CVE in een geïsoleerde interne service is een ander risico dan dezelfde CVE in een publieke API.
Reken erop dat er de komende tijd nieuwe CVEs binnenkomen vanuit programma's als Glasswing (eerste resultaten begin juli), OpenAI, Google, en de groeiende stroom AI-gestuurde vulnerability reports.
Kijk naar je eigen stack:
“Te riskant” om te migreren. Maar je kunt hem niet hotfixen. Er is geen patch-pad. Je moet eerst migreren voordat je kunt reageren.
Kwetsbaarheden in Linux, CVEs in tools die in de container geïnstalleerd zijn. De onderliggende OS-packages krijgen geen updates meer.
Een CVE in een transitieve dependency? Als de tussenliggende package niet meer onderhouden wordt, is er niemand die de gefixte versie binnenhaalt. Je zit vast in een keten die je niet kunt updaten.
Beeld: AI-gegenereerd
Wat kun je doen?
Mythos is er al. De Glasswing-partners gebruiken het nu. De eerste CVEs die daaruit voortkomen kunnen elk moment verschijnen, het officiele rapport volgt in juli. De eerste stap is niet een agent installeren. Het begint bij inventariseren, en dan drie dingen: legacy migreren, preventie inrichten, en klaar zijn om te reageren.
Inventariseer
Genereer een Software Bill of Materials (SBOM) van je services. Identificeer welke dependencies end-of-life zijn en welke packages niet meer onderhouden worden.
Legacy migreren
Migreren. Kun je dat niet direct, isoleer: netwerksegmentatie, privileges beperken.
Vervangen. Geen updates, geen patches, geen uitweg.
Rebuilden op supported base image. Runtime monitoring als tussenoplossing.
Isolatie is tijdwinst, geen oplossing. Migratie is de enige structurele uitweg.
Het vliegwiel: begin niet bij je meest complexe monoliet. Kies een service met een overzichtelijke dependency tree en laat daar een AI-agent de migratie van begin tot eind uitvoeren. Zo valideer je de werkwijze in een beheersbare omgeving.
Zodra die eerste service weer op een supported stack draait, heeft je team de blauwdruk en het bewijs dat het werkt. De tweede service gaat sneller. De derde nog sneller. Dat is het vliegwiel.
Preventie
Automatiseer patchbare CVEs met Dependabot of Renovate. Tegen supply chain risico's (zoals Axios): gebruik lockfiles en npm ci in plaats van npm install. Anders kan je build ongemerkt nieuwe dependency-versies binnenhalen, precies wat er bij supply chain attacks misgaat. Monitor daarnaast op onverwachte wijzigingen in je dependency tree.
Response
Als er een CVE binnenkomt die je raakt: hoe snel kun je deployen? Heb je een hotfix-pad buiten je normale releasecyclus? Wie beslist wat prioriteit krijgt? Kun je rollbacken als de fix iets breekt? Beoordeel per service: is de kwetsbare code bereikbaar (reachability)? Hoe waarschijnlijk is exploitatie (EPSS)? Wat is de business-impact?
Het doel is niet een perfect schone stack. Het doel is een team en een systeem dat snel genoeg kan reageren als het erop aankomt.
AI als versneller
Elk van deze stappen kan zonder AI. Maar AI-agents kunnen het fixen en migreren versnellen. Een agent kan je SBOM analyseren en risico's prioriteren. Bij migraties kan een agent breaking changes detecteren, tests aanpassen en het migratiepad uitwerken. Bij CVE-response kan een agent bepalen of de kwetsbare code in jouw context daadwerkelijk bereikbaar is. Scanning-tools vinden duizenden potentiële lekken, maar het merendeel is niet exploiteerbaar omdat de code nooit wordt uitgevoerd. Een agent kan dat onderscheid maken voor jouw specifieke codebase.
Let wel op: sneller moderniseren met AI brengt eigen risico's met zich mee. Hoe je voorkomt dat AI-gegenereerde code je meer problemen oplevert dan oplost, beschrijf ik in mijn artikel over AI-adoptie.
Kan jouw team snel genoeg reageren als er morgen een kritieke CVE binnenkomt?
Lees ook: Van AI-experimenten naar AI-adoptie · Claude Code in .NET development · Context opbouwen in Claude Code