AI brengt nieuwe beveiligingsproblemen met zich mee voor de opensourcewereld en versterkt bestaande problemen. Maar het helpt ook om deze op te lossen. Pakketbeheer-expert Andrew Nesbitt vertelt hoe en waarom.
De verborgen beveiligingsrisico’s van softwareafhankelijkheden
Andrew Nesbitt doet onderzoek naar pakketbeheerders en ontwikkelt tools en datasets die moeten helpen om opensource beter te begrijpen. Hiervoor brengt hij de infrastructuur achter opensourcesoftware in kaart: pakketmetadata, afhankelijkheden (dependency’s) en de beveiligingseigenschappen van softwareketens. In een gesprek met c’t vertelt hij over de gevolgen van AI voor de veiligheid van (opensource)software en over manieren om oude en nieuwe problemen aan te pakken.
Andrew, je houdt zich bezig met pakketbeheerders. Zou je zeggen dat de beveiliging van softwaretoeleveringsketens, waarvoor AI momenteel een probleem vormt, hiermee samenhangt?
Andrew Nesbitt: Het hangt allemaal met elkaar samen en het is moeilijk om de afzonderlijke aspecten van elkaar te scheiden, maar enkele punten vallen me momenteel bijzonder op. Veel configuraties van pakketbeheerders hebben simpelweg slechte standaardinstellingen. Voorheen vormden deze geen groot probleem, omdat softwareontwikkelaars toen niet zoveel pakketten installeerden en het vaak dezelfde waren. Tegenwoordig raken ze verstrikt in een jungle van dependency’s.
In hoeverre vormen veel dependency’s een potentieel beveiligingsprobleem?
Kwaadwillende actoren hebben ingezien hoe eenvoudig het is om malware in pakketten te smokkelen, vooral in pakketten die op de achtergrond worden geïnstalleerd als dependency van een dependency. Ontwikkelaars nemen deze pakketten ongezien mee en vertrouwen erop dat de maintainers op hun beurt hun dependency’s en de dependency’s van hun dependency’s in de gaten houden.
Zorgen de slechte defaults ervoor dat de maintainers dat ook niet in de gaten hebben?
Als onderdeel van het installatieproces voor een bibliotheek kunnen veel pakketbeheerders willekeurige code uitvoeren. Ofwel omdat ze een deel van de gedownloade software moeten compileren, ofwel omdat er mogelijk een post-install-script is dat nog meer software achteraf installeert. Of het post-install-script stelt eerst vast op welk systeem het zich bevindt en past de software vervolgens dienovereenkomstig aan, zodat deze bijvoorbeeld op een Mac draait.
Vroeger was dit niet zozeer een probleem maar een feature: alleen zo konden pakketten dynamisch worden aangepast aan al de verschillende systemen waarop ze werden geïnstalleerd. Misschien wordt een library op Windows geïnstalleerd, wellicht met een oude versie van Python. En misschien heeft deze, om onder Python 2 te functioneren, een paar extra dependency’s nodig die bij Python 3 niet nodig zijn.
Of als de library onder Linux wordt geïnstalleerd, zijn er misschien weer andere dependency’s nodig, omdat het besturingssysteem bepaalde vereisten niet standaard ondersteunt.
Aanvallers kunnen hiervan misbruik maken en proberen verdere transitieve dependency’s [dependency’s van dependency’s, red.] binnen te sluizen, waarvan de code vervolgens tijdens de installatie op de achtergrond wordt uitgevoerd.
Als een aanvaller erin slaagt een dependency te compromitteren, kan hij zijn schadelijke code niet alleen in de lokale omgevingen van individuele ontwikkelaars binnensluizen, maar ook in hun CI. En de CI/CD-pipeline [Continuous Integration/Continuous Delivery/Deployment, geautomatiseerd proces voor de ontwikkeling, levering en uitrol van software, red.] is de plek geworden waar veel pakketten inmiddels worden gepubliceerd.
Dat gebeurt automatisch?
Ja precies. De ontwikkelaar van een library publiceert de code voor een update vaak niet meer zelf, maar tagt een release op GitHub, en GitHub Actions automatiseert vervolgens het releaseproces. Dankzij de op GitHub bewaarde sleutel wordt de update via alle afzonderlijke pakketbeheerders gepubliceerd en beschikbaar gesteld.
Is er iets wat je hiertegen kunt doen?
Bij veel pakketbeheerders kun je de post-install-scripts uitschakelen, zodat ze niet standaard worden uitgevoerd. Het probleem is alleen: deze standaardinstellingen zijn er om voor een goede developer experience te zorgen. De maintainers van verschillende pakketbeheerders beginnen langzaam te beseffen dat dit gevaarlijk is en passen de standaardinstellingen aan, maar dat verstoort de werkprocessen van de gebruikers. Daarom verloopt dit veranderingsproces erg traag.
Een andere maatregel zijn de zogenaamde dependency cooldowns. Dit is in feite een filter dat bepaalt dat er niets wordt geïnstalleerd dat niet – laten we zeggen – minstens zeven dagen geleden is gepubliceerd. Alles wat nieuwer is, wordt in eerste instantie geweigerd. Het idee hierachter is dat securitybedrijven nieuw gepubliceerde pakketten onderzoeken en dat het grootste deel van alle malware in de dagen na de publicatie wordt ontdekt.
Pakketten die besmet zijn met schadelijke code worden in het beste geval uit de registry’s verwijderd voordat gebruikers er überhaupt mee in aanraking komen. Maar de community is hierover verdeeld.
Het proces waarbij defecten in de code uitgroeien tot een acuut misbruikt beveiligingslek, is door AI enorm versneld. Door zeven dagen te wachten met het installeren van updates, druis je dan niet in tegen het principe dat je patches zo snel mogelijk moet installeren?
Deze twee kwesties botsen juist op het meest ongelegen moment op elkaar. Aan de ene kant is er het malwareprobleem van de pakketbeheerders, dat je wil aanpakken door minder vaak updates te installeren. Aan de andere kant is er de explosieve toename en verbetering van tools voor het opsporen van beveiligingslekken in opensourceprojecten. LLM’s vinden tegenwoordig met gemak kwetsbaarheden die mogelijk al lang bestaan, maar waar voorheen alleen zeer ervaren beveiligingsonderzoekers in staat waren geweest om ze te ontdekken.
Hoe zou je met deze discrepantie omgaan?
Met tools zoals Dependabot of Renovate is het mogelijk om een cooldown in te stellen voor de pakketten die je integreert. Zelf heb ik voor de meeste een cooldown van zeven dagen ingesteld. Als het een security advisory betreft dat door een mens is gecontroleerd en via de GitHub Advisory Database of een CVE-programma is gepubliceerd, zou je ondanks de cooldownfase een pull-request aanmaken en erop wijzen dat er een beveiligingsupdate is die zo snel mogelijk moet worden geïnstalleerd. Meestal worden de waarschuwingen voor dringende beveiligingsupdates apart gemarkeerd, zodat je ze niet over het hoofd ziet.
Ik maak wel eens grapjes dat Copilot overal in GitHub zit, behalve in Dependabot. Dependabot kan geen AI-functies krijgen, omdat de inhoud van de pakketten die Dependabot zou willen updaten dan niet meer te vertrouwen zou zijn. De inhoud zou erop gericht kunnen zijn om juist misbruik te maken van Dependabot.
Dependabot is een tool voor dependency-beheer van GitHub, die softwareontwikkelaars helpt om de dependency’s van hun projecten up-to-date te houden. Nadat we dit interview hadden gehouden, heeft GitHub daadwerkelijk een afkoelingsperiode van drie dagen ingesteld voor Dependabot. Pull-requests voor versie-updates van dependency’s worden pas daarna aangemaakt. Uitzondering hierop vormen beveiligingsupdates die betrekking hebben op een bekende kwetsbaarheid en die gepaard gaan met een gepubliceerd advisory voor het pakket.
Het feit dat er menselijke reviewers betrokken zijn bij de processen van GitHub, zorgt voor een zekere mate van vertrouwen. Aan de andere kant heeft GitHub onlangs een blogpost gepubliceerd, waarin ze schrijven dat ze volledig overspoeld worden met reports en advisory’s, en er inmiddels een back-log van meerdere weken is gecumuleerd.
Als een beveiligingslek als kritiek wordt ingedeeld, mag natuurlijk worden aangenomen dat het prioriteit krijgt, maar het hele systeem is simpelweg hopeloos overbelast. De enorme omvang dwingt de beoordelaars om zich te haasten. Maar als ze minder tijd hebben voor de beoordelingen, kan het mogelijk gemakkelijker gebeuren dat aanvallers er toch in slagen schadelijke code in de beveiligingsupdates te smokkelen. En als er bij de beoordelingen LLM’s worden ingezet, zet dat op zijn beurt de deur wijd open voor prompt-injecties [1].
Is de situatie uit de hand gelopen?
Ik zou niet zeggen dat we op het punt zijn gekomen dat de situatie uit de hand is gelopen. Maar de situatie is over het algemeen gespannen. Elke dag worden met behulp van LLM’s honderden beveiligingslekken in opensourcesoftware ontdekt, niet alleen in de populaire projecten, maar juist ook in die projecten die weliswaar veel worden gebruikt, maar tot nu toe weinig aandacht hebben gekregen. Geen van deze systemen, die tot nu toe een toereikend beveiligingsniveau hebben gegarandeerd, is ontworpen om deze omvang aan te kunnen.
We zien het aan Project Glasswing: de aangesloten bedrijven vinden tienduizenden beveiligingslekken in hun dependency-trees. Sommige van deze bedrijven gebruiken 60.000 verschillende pakketten verspreid over al hun organisaties. En nu vragen ze zich af: “Hoe moeten we in vredesnaam al deze beveiligingslekken en bugs op prioriteit sorteren en publiceren? En hoe moeten de maintainers al die fixes controleren en patches beschikbaar stellen?”
Een ander probleem is dat veel opensourceprojecten door één persoon worden onderhouden. En veel van deze beheerders doen dat vrijwillig, in hun vrije tijd. Ze staan nu onder enorme druk. In navolging van het cURL-project hebben enkele projecten juli van dit jaar uitgeroepen tot pauzemaand, om de beheerders wat te ontlasten. Ze noemen het de ‘Summer of Bliss’ (zie het artikel Hoe AI opensourcebeheerders onder druk zet in deze serie).
Maar dat is geen blijvende oplossing voor het probleem.
Ik werk al een paar maanden samen met Alpha-Omega (zie het artikel over de Vulnpocalypse in deze serie) om de situatie te verlichten. Alpha-Omega [een IT-securityproject onder de vlag van de Opensource Security Foundation/Linux Foundation, red.] betaalt beheerders van verschillende ecosystemen – waaronder Perl, Java, Apache, Python, Ruby, Erlang en JavaScript – om de meldingen van beveiligingslekken op urgentie te sorteren.
Denk je dat de situatie zal verbeteren als alle gevonden beveiligingslekken zijn verholpen?
In onze vergaderingen melden de maintainers dat het aantal binnenkomende meldingen de laatste tijd afneemt. Er komen weliswaar nog steeds meldingen binnen, maar het gaat steeds vaker om duplicaten. De achtergrondruis zal dus waarschijnlijk afnemen.
Ik geloof echter niet dat het ooit weer terug zal gaan naar het niveau van vroeger. Mensen richten hun LLM securityscanners inmiddels op elke afzonderlijke commit. Daarbij vinden ze veel potentiële kwetsbaarheden die anders niet ontdekt zouden zijn, waaronder veel met een geringe impact.
Vroeger werden die vaak genegeerd, maar het probleem is nu dat de nieuwere LLM’s zo goed zijn in het aan elkaar koppelen van deze bugs dat ze toch misbruikt kunnen worden. Het is dus niet voldoende om je alleen te concentreren op de kwetsbaarheden die als kritiek of hoog zijn ingedeeld.
Zal er op een gegeven moment een punt worden bereikt waarop er geen kwetsbaarheden meer zijn?
Zelfs als je op een gegeven moment alle bestaande bugs zou hebben geëlimineerd, blijven mensen code publiceren en daar zitten dan weer nieuwe kwetsbaarheden in. En vaak zijn bestaande oplossingen voor een probleem op hun beurt weer onvolledig. IT-beveiliging is nu eenmaal complex en juist onervaren softwareontwikkelaars hebben vaak moeite om dergelijke problemen volledig te begrijpen.
Steeds meer softwareontwikkelaars gebruiken LLM’s om te programmeren [2]. Als de nieuwere AI-modellen zo goed zijn in het opsporen van kwetsbaarheden, zijn ze dan misschien ook goed in het schrijven van veilige code?
Alleen als je dat expliciet aangeeft. Bij coding-harnassen [toepassing rondom het AI-model die bepaalt hoe een agent zich in de praktijk gedraagt, red.] en LLM’s is er geen standaardinstelling die ervoor zorgt dat ze veilige code schrijven. Ze zijn veel meer erop gericht om de gebruikers zo lang mogelijk aan zich te binden. Misschien verandert dat op een gegeven moment en geven ze dan prioriteit aan veilige code, maar het kan maanden of jaren duren voordat dergelijke veranderingen bij de gebruikers doordringen.
Individuele ontwikkelaars kunnen natuurlijk security reviews expliciet in hun processen integreren, maar zolang dat niet de standaard is, blijft onveilige code de standaard.
Eind juni heb je een blogpost gepubliceerd over een project genaamd Scrutineer, dat is ontstaan in het kader van je samenwerking met Alpha-Omega. Moet dat de problemen oplossen?
Scrutineer is een opensource AI-harnas voor door LLM aangestuurde geautomatiseerde beveiligingsaudits, vergelijkbaar met Codex of Claude Code, maar de focus ligt meer op afzonderlijke pakketten. Scrutineer kijkt ook naar de dependency’s van deze pakketten. Als het kwetsbaarheden vindt, probeert het vast te stellen of en in hoeverre deze van invloed kunnen zijn op de pakketten die ervan afhankelijk zijn.
Zo krijg je een beter beeld van de ‘blast radius’ van een ontdekte kwetsbaarheid. Dan kun je bijvoorbeeld zeggen dat een bevinding weliswaar voldoet aan de criteria om als beveiligingslek te worden aangemerkt, maar dat er in de praktijk geen manier is om er misbruik van te maken. De maintainers zouden dan met dergelijke reports met rust worden gelaten.
Alpha-Omega heeft IT-beveiligingsexperts in dienst genomen die met hun expertise en hun contacten met de maintainers moeten helpen om de belangrijkste pakketten in hun respectievelijke ecosystemen te beveiligen. Zij maken al gebruik van Scrutineer.
Is AI daarmee eerder een zegen dan een vloek voor de IT-beveiliging?
Het is moeilijk te voorspellen wat er gaat gebeuren. Vooral omdat we niet weten of er binnenkort nog verder verfijnde modellen op de markt zullen komen. De zogenaamde open-weight-modellen lopen doorgaans ongeveer zes maanden achter op de frontier-modellen [met de lancering van de Kimi K3, die plaatsvond nadat dit interview werd afgenomen, is deze periode inmiddels aanzienlijk ingekort, red.].
Aan het einde van het jaar zullen we dus mogelijk open-weight-modellen zien die veiligheidsscans kunnen uitvoeren die net zo goed zijn als die van Anthropics Mythos. Dat vind ik behoorlijk verontrustend. Als je de veiligheidsbarrières kunt wegnemen, kun je deze modellen gewoon op websites of softwaresystemen richten en zeggen “zoek een paar kwetsbaarheden”. En als je maar genoeg tokens of genoeg energie hebt om het continu opnieuw te laten draaien, dan vind je uiteindelijk ook wel iets. Daarom heerst er al een zekere mate van paniek. Iedereen die hier ook maar een beetje over nadenkt, komt tot de conclusie dat ze hun systemen nu moeten beveiligen.
Kunnen ze dat niet, omdat de taak veel te groot en ingewikkeld is?
De afgelopen maanden waren hectisch. Er was een enorme toename van securityproblemen. Ik beschouw dat als een symptoom van het gebrek aan investeringen in opensource. Veel grote bedrijven hebben de afgelopen tien jaar intensief geprofiteerd van opensource en weinig teruggegeven. Er komt maar heel weinig geld terecht bij de afzonderlijke projecten. Tegelijkertijd hangt de veiligheid van de software-supply-chain af van vrijwillige beheerders zonder contracten. Dat wreekt zich nu.
Ik denk dat mensen in de toekomst veel voorzichtiger zullen zijn met het gebruik van te veel verschillende projecten van onbekende aanbieders. Dependency-trees zullen krimpen en er zal een concentratie ontstaan op een klein aantal zeer populaire opensourceprojecten.
Tegelijkertijd zullen bedrijven proberen om geteste, geharde versies van deze projecten op de markt te brengen. Dat baart me zorgen. Ze proberen een deel van de opensourcekoek voor zichzelf op te eisen, in plaats van de maintainers te ondersteunen. Ze bouwen een alternatieve versie, omdat bedrijven veel liever – bijna zoals bij een verzekering – betalen om iemand anders de verantwoordelijkheid te laten dragen, dan dat ze het onderhoud van de projecten rechtstreeks financieren.
Kathrin Stoll en Daniel Dupré
Literatuur
[1] Kathrin Stoll en Alieke van Sommeren, Mede mogelijk gemaakt door: Claude Code, c’t 8-9/2026, p.34
[2] Sylvester Tremmel en Noud van Kruysbergen, Promptware: aanvallen die prompt-injectie overstijgen, c’t 7/2026, p.142
Links bij dit artikel
De gevolgen van AI voor de veiligheid van softwarebeheer
Scrutineer
Blogbericht hierover
Dependency-Management
Renovate Dependency Tool
Renovate is een tool voor het beheer van depemdency’s, waarmee een cooldown voor geïntegreerde pakketten kan worden ingesteld.
Security
GitHub Advisory Database
De GitHub Advisory Database dient voor het publiceren van beveiligingsupdates en gecontroleerde beveiligingsadviezen.
GitHub-blogbericht over beveiliging
GitHub beschrijft in een blogbericht de overbelasting als gevolg van de stortvloed aan beveiligingsmeldingen en -adviezen.
Praat mee