Een AI coding assistant kan ontwikkelaars helpen sneller en met minder fouten code te schrijven. Maar uit een recente casus van Mandiant blijkt dat dezelfde automatisering ook kan worden misbruikt: een aanvaller kaapte een actieve sessie bij een software-as-a-service (SaaS) provider en gebruikte die toegang om schadelijke stappen door te voeren in het ontwikkelproces. Daarna verspreidde de malware zich via interne code-repositories en wist de aanvaller repository-secrets en broncode te verzamelen.
In dit artikel leggen we uit hoe het incident waarschijnlijk is verlopen, welke sleutelstappen Mandiant beschrijft en welke controles teams kunnen inzetten om AI-ondersteunde ontwikkeling veiliger te maken.
Wat er misging met de AI coding assistant
Volgens Mandiant werd bij een onbekende SaaS-partij een actieve AI coding assistant sessie overgenomen door een aanvaller. Vervolgens maakte de aanvaller gebruik van het feit dat de assistent aanbevelingen doet die door ontwikkelaars worden overgenomen in hun werk.
Het scenario begon met een gerichte aanbeveling: de assistent adviseerde software die door de aanvaller was “vergiftigd” (poisoned). Zodra een medewerker deze aanbeveling accepteerde, ontstond er een route voor de aanvaller om verder te gaan.
Van aanbeveling naar infostealer
Na acceptatie van de AI-aanbeveling gebruikte de aanvaller de actieve sessie van de developer om een infostealer te installeren. Zo’n infostealer is gericht op het verzamelen van gevoelige informatie—in dit geval vooral gegevens die waardevol zijn voor toegang tot systemen en code.
Daarbij stal de aanvaller ook GitHub OAuth-tokens. Dat is relevant, omdat OAuth-tokens een directe manier kunnen zijn om namens een gebruiker of organisatie acties uit te voeren, bijvoorbeeld om repositories te lezen, bewerken of verder te verkennen.
Shai-Hulud verspreidt zich via interne repositories
Daarna zette de aanvaller een zelfverspreidende wormfamilie in: Shai-Hulud. Mandiant beschrijft dat de worm zich verspreidde over ongeveer 100 interne code-repositories.
Dit is een belangrijk patroon: het incident is niet beperkt gebleven tot één project of één medewerker. Door zich te verspreiden binnen de ontwikkelomgeving vergroot de aanvaller de kans op het stelen van secrets en het verkrijgen van broncode van meerdere producten.
Dubbele besmetting: tweede infectie via het eigen namespace
Naast de verspreiding via interne repositories beschrijft Mandiant ook dat de aanvaller een pakket poisonde in het officiële namespace van het betreffende platform. Vervolgens haalde een andere medewerker een gecompromitteerde versie van dat pakket op.
Daardoor ontstond een tweede infectieronde. Met andere woorden: niet alleen de eerste gebruiker werd getroffen via een AI-aanbeveling, maar ook via een latere installatie door iemand anders die het “geautoriseerde” pakket vertrouwt.
Wat weten we (en wat niet) over de overname
De publieke casus van Mandiant geeft geen exacte timing van de inbraak en vermeldt ook niet hoe de aanvaller de actieve AI coding assistant sessie precies heeft kunnen kapen. Dat betekent dat we voorzichtig moeten zijn met het invullen van details die niet in het rapport staan.
Wel duidelijk is dat de aanvaller de workflow van de ontwikkelaar gebruikte: eerst invloed via een aanbeveling, daarna uitvoering via de lopende sessie.
Waarom dit past in een bredere trend
Mandiant wijst er in bredere rapportages op dat aanvallers hun inzet van AI hebben verschoven. Waar generatieve AI lange tijd vooral werd gebruikt om werk sneller te maken, ziet Mandiant in recente ontwikkelingen meer verschuiving naar grote taalmodellen voor het bouwen van malware en het uitvoeren van actieve aanvallen.
De kern van deze casus past in die trend: niet alleen “code schrijven”, maar ook beslissen en handelen binnen een workflow—in dit geval door een AI-assistent te laten bijdragen aan de verspreiding van een schadelijke payload.
Beschermmaatregelen voor AI-ondersteunde ontwikkeling
Voor verdedigers formuleert Mandiant drie concrete controles voor AI-assisted development. Hieronder vertalen we ze naar praktisch toepasbare richtingen voor teams die met AI-tools en externe pakketten werken.
1) Controleer AI-aanbevolen dependencies
Als een AI coding assistant derde partijen adviseert (libraries, tools of pakketten), wil je die streng verifiëren. Mandiant adviseert het checken van aanbevolen dependencies via cryptografische checksums en goedgekeurde allowlists.
Zo voorkom je dat “aanbevolen” automatisch “vertrouwd” wordt. Een pakket kan er immers legitiem uitzien, terwijl de inhoud is aangepast.
2) Houd secrets buiten het bereik van extensies
Een tweede risico zit in toegang: Mandiant benadrukt dat raw API keys, langlevende OAuth-tokens en andere geheimen niet direct bereikbaar moeten zijn voor extensies of tooling die in de ontwikkelomgeving draait.
Met andere woorden: implementeer een model waarin gevoelige credentials afgeschermd zijn. Dat verkleint de impact wanneer een sessie of component wordt misbruikt.
3) Routeer dependency-verkeer via gecontroleerde repos
Ten derde adviseert Mandiant dependencyverkeer te laten lopen via gecontroleerde interne repositories. Daarmee leg je de weg vast die pakketten afleggen voordat ze in builds terechtkomen.
Als een aanvaller een pakket “vergiftigt” in een externe bron, heb je met interne controles een extra laag om het binnendringen in je software supply chain te detecteren of tegen te houden.
Extra context: aanvallen op ontwikkelaarstools en credentials
Mandiant beschrijft dat recente aanvallen uit dezelfde Shai-Hulud-achtige familie ook gericht waren op developer tools en credentials. In augustus werd bijvoorbeeld melding gemaakt van een worm die honderden pakketten vergiftigde en bovendien hooks installeerde voor hulpmiddelen die worden gebruikt om code te ontwikkelen—waarbij ook varianten werden gevonden die op veel locaties zochten naar credentials.
Het is hierbij wel belangrijk dat Mandiant aangeeft dat het om separate campagnes ging en dat de beschikbare bewijzen de incidenten niet direct aan de genoemde SaaS-intrusie koppelen.
Praktische checklist voor teams
Wil je de kans verkleinen dat een AI coding assistant onbedoeld onderdeel wordt van een aanval? Gebruik dan deze compacte checklist als startpunt:
- Allowlists en checksum-validatie voor elk AI-advies dat leidt tot nieuwe dependencies.
- Minimaliseer blootstelling van secrets (API keys en OAuth-tokens) richting extensies of ontwikkelplugins.
- Gebruik interne package-routing (gecontroleerde repositories) voor dependency traffic.
- Let op tweede-orde infecties: één gecompromitteerde package kan later door anderen opnieuw worden geïnstalleerd.
- Monitor en audit installaties en wijzigingen in CI/CD en repository-werkstromen.
Conclusie: AI helpt, maar vraagt om extra supply chain discipline
De casus laat zien dat een AI coding assistant niet alleen een productiviteitsinstrument is, maar ook een schakel in het software supply chain proces. Zodra een aanvaller de workflow kan beïnvloeden—bijvoorbeeld via een “geaccepteerde” aanbeveling—kan dat leiden tot het installeren van schadelijke code, het stelen van tokens en het verspreiden van een worm over meerdere interne repositories.
Met gerichte controles zoals dependency-verificatie, het afschermen van secrets en gecontroleerde routing van package-verkeer kunnen organisaties de impact van dit soort scenario’s aanzienlijk beperken.
Wil je daarnaast begrijpen hoe “losse checks” niet genoeg zijn en hoe je beter kunt testen op echte aanvalsketens? Lees dan ook waarom losse checks niet werken.
Bron: https://thehackernews.com/2026/09/attacker-hijacks-ai-coding-assistant.html
