Geeky Saturday: hoe één VS Code-extensie kan uitgroeien tot een supply chain crisis

Het is zaterdag. Dus tijd voor een onderwerp dat je doordeweeks vaak te snel wegzet als 'technisch detail', terwijl het eigenlijk een boardroomprobleem is. Een developer installeert een extensie. Die extensie krijgt een update. Die update blijkt kwaadaardig. En ineens staat interne broncode buiten de deur.

Dat is, in het kort, waarom de recente GitHub-case zo interessant is. Niet omdat GitHub 'gewoon gehackt' is, maar omdat het laat zien hoe kwetsbaar moderne organisaties zijn geworden voor tooling die diep in de dagelijkse workflow zit. Volgens berichtgeving over het incident bevestigde GitHub dat een employee device werd gecompromitteerd via een poisoned VS Code extension, waarna interne repositories zijn geëxfiltreerd. De claim van ongeveer 3.800 interne repositories komt volgens GitHub 'directionally consistent' overeen met het onderzoek tot nu toe, terwijl GitHub stelt geen bewijs te hebben dat klantrepositories of externe klantomgevingen zijn geraakt.

Dat klinkt als een incident bij een grote Amerikaanse techpartij. Maar dat is te makkelijk. Dit raakt direct aan hoe vrijwel iedere organisatie vandaag werkt: met ontwikkelaars, extensies, open-source packages, CI/CD, cloudtokens, browsertools, AI-code-assistenten, SaaS-platforms en steeds meer automatische updates.

De echte vraag is dus niet: 'Hoe kon dit bij GitHub gebeuren?' De echte vraag is: 'Hoeveel GitHub-achtige risico's draaien er vandaag al in onze eigen omgeving?'

Dit was geen klassieke hack, dit was een vertrouwensaanval

De interessantste aanvallen zijn vaak niet de aanvallen die hard binnenkomen. Het zijn de aanvallen die eruitzien als normaal gedrag. Een VS Code-extensie is voor veel developers geen verdacht object. Het is een productiviteitstool. Net zoals een npm-package, een PyPI-library, een GitHub Action, een browserextensie, een Copilot-plugin of een AI-agent. Developers installeren die tools omdat ze sneller willen werken. En precies daar zit het probleem: de toolinglaag rond developers is in veel organisaties sneller gegroeid dan het securitymodel eromheen.

Bij GitHub ging het volgens de berichtgeving om een gecompromitteerd employee device en een poisoned VS Code extension. De aanvallers konden interne repositories exfiltreren, waarna GitHub naar eigen zeggen de extensie verwijderde, het endpoint isoleerde en kritieke secrets roteerde. Het ging niet om een npm-package of PyPI-package als directe ingang, maar om een legitiem gebruikte code-extensie die via auto-update een kwaadaardige versie binnenhaalde. Vervolgens wordt de link gelegd met TeamPCP, npm/PyPI-wormen en gestolen credentials die later opnieuw worden gebruikt in vervolgincidenten.

Dat patroon is belangrijker dan de exacte extensienaam. Want als aanvallers developer tooling kunnen misbruiken, hebben ze toegang tot precies de plek waar de kroonjuwelen van moderne organisaties samenkomen: code, secrets, cloudtoegang, deploymentrechten, documentatie, interne tickets, API-sleutels en soms zelfs klantcontext.

Waarom TeamPCP zo goed past in dit nieuwe aanvalspatroon

De naam TeamPCP komt in meerdere recente berichten terug als actor achter een golf van software supply chain-aanvallen. Volgens Wired heeft de groep sinds eind 2025 meer dan twintig aanvalsgolven uitgevoerd, meer dan 500 tools gecompromitteerd en impact veroorzaakt bij partijen als GitHub, Anthropic, OpenAI en de Europese Commissie. Wired beschrijft het patroon als een 'flywheel of supply chain compromises', waarbij gestolen credentials worden gebruikt om nieuwe tools, packages en infrastructuur te besmetten.

Dat is precies waarom deze case verder gaat dan GitHub. Een klassieke infostealer steelt wachtwoorden. Een moderne supply-chain infostealer steelt de mogelijkheid om vertrouwen te misbruiken. Denk aan maintainer accounts, npm-tokens, PyPI-tokens, GitHub personal access tokens, CI/CD-secrets, cloud credentials, SSH-keys, code signing certificates, package provenance of release workflows en toegang tot private repositories.

Daarmee hoeft een aanvaller niet elke organisatie apart te hacken. Hij kan één vertrouwd schakelpunt misbruiken en daarna meeliften op de distributieketen. TechRadar meldde bijvoorbeeld dat TeamPCP in een gecoördineerde campagne 639 malicious npm-versies van 323 unieke packages publiceerde in ongeveer één uur, gericht op developers, maintainers en CI/CD-omgevingen. De malware was volgens die berichtgeving gericht op credential theft en het compromitteren van ontwikkelomgevingen.

Dit is het punt waarop supply chain security ophoudt een softwareprobleem te zijn. Het wordt een bedrijfsrisico.

De ontwikkelomgeving is nu een productieomgeving

Veel organisaties beveiligen productieomgevingen streng, maar behandelen developer workstations nog steeds als flexibele werkplekken. Dat is logisch vanuit productiviteit, maar steeds minder verdedigbaar vanuit risico.

Een developer laptop is vandaag niet zomaar een laptop. Het is vaak een toegangspoort tot broncode, repositories, pipelines, cloudomgevingen, staging en productie, SaaS-adminportalen, secrets, klantintegraties, deploymentprocessen, AI-code-assistenten en interne documentatie.

Daarom moeten we anders naar developer tooling kijken. Een VS Code-extensie is niet alleen een extensie. Een npm-package is niet alleen een dependency. Een GitHub Action is niet alleen automation. Een AI-agent is niet alleen een handige assistent. Het zijn allemaal stukjes uitvoerbare vertrouwensinfrastructuur.

En juist daarin zit het gevaar. VS Code-extensies draaien in een context waarin ze vaak bestanden kunnen lezen, terminals kunnen openen, configuraties kunnen benaderen en interactie hebben met andere developer tools. Onderzoek uit 2024 naar VS Code-extensies liet zien dat 8,5% van 27.261 onderzochte extensies risico's had rond credential-gerelateerde datalekken via onder meer commands, user input en configuraties.

Dat betekent niet dat iedere extensie gevaarlijk is. Het betekent wel dat de categorie serieus moet worden genomen. In veel organisaties is het installatiebeleid voor developer-extensies minder volwassen dan het beleid voor productie-firewalls. Terwijl de impact van een gecompromitteerde developeromgeving enorm kan zijn.

Auto-update is gemak, maar ook aanvalssnelheid

Een van de meest onderschatte aspecten van deze case is auto-update. Automatische updates zijn meestal goed. Ze dichten kwetsbaarheden, houden software actueel en verlagen beheerkosten. Maar bij supply-chainaanvallen kan auto-update ook het distributiekanaal van de aanvaller worden. Als een legitieme extensie, package of tool wordt overgenomen, verspreidt de kwaadaardige versie zich via hetzelfde mechanisme dat normaal gesproken veiligheid en gemak brengt.

Wired schrijft dat automatische updates de verspreiding van TeamPCP-malware versnelden en dat securityprofessionals cooldown-perioden en strengere inspectie van open-source tools aanbevelen voordat updates breed worden uitgerold.

Dat is een lastig gesprek voor organisaties. Want niemand wil terug naar handmatig patchen op gevoel. Maar blind vertrouwen op iedere update uit iedere marketplace is ook niet meer houdbaar. De volwassen middenweg is risicogestuurd updatebeleid: kritieke securitypatches snel, developer tooling gecontroleerd, nieuwe extensieversies met vertraging of allowlisting, packages met minimum package age, geautomatiseerde dependency scanning, observability op afwijkend gedrag en strikte secretrotatie bij signalen van compromise.

De vraag is dus niet of je updates moet vertragen. De vraag is welke updates zó dicht op je kroonjuwelen zitten dat je ze niet langer blind door de organisatie wilt laten rollen.

Waarom AI dit probleem versnelt

Tot nu toe ging het vooral over developer tooling. Maar AI maakt dit probleem groter. Niet omdat AI 'slecht' is, maar omdat AI de snelheid, schaal en automatisering van zowel aanvallers als verdedigers verhoogt. AI-code-assistenten, agentic coding tools en browser- of IDE-extensions zitten steeds dichter op dezelfde plek waar deze GitHub-case begon: de developer workflow.

Daar komt nog iets bij. AI kan aanvallers helpen om sneller packages te analyseren, kwetsbaarheden te vinden, phishing overtuigender te maken, malwarevarianten te genereren en gestolen secrets slimmer te benutten. Tegelijk kan AI verdedigers helpen om sneller anomalieën te detecteren, code te reviewen, kwetsbaarheden te prioriteren en incidentrespons te versnellen.

De recente discussie rond Anthropic's Claude Mythos laat goed zien hoe scherp die balans wordt. Reuters meldde dat Anthropic deelnemers aan Project Glasswing toestaat om cybersecuritybevindingen die met Mythos zijn gevonden breder te delen. Mythos is een niet-publiek beschikbaar model voor cybersecurityonderzoek, met toegang voor geselecteerde partners, bedoeld om kwetsbaarheden te vinden en defensieve respons te verbeteren. Tegelijk zijn er zorgen dat modellen zoals Mythos ook aanvallende capaciteiten kunnen versterken. Reuters meldde dat Anthropic het Financial Stability Board zou briefen over kwetsbaarheden in het financiële systeem die met Mythos zijn gevonden, juist omdat zulke modellen zowel defensief waardevol als potentieel risicovol zijn.

AI-hacks bestrijd je niet met alleen AI-security

De reflex bij AI-gedreven dreiging is vaak: 'Dan moeten we ook AI-security kopen.' Dat klopt deels, maar niet volledig. AI helpt, maar het fundament blijft hetzelfde: identity, least privilege, endpoint hardening, logging, segmentation, secret management, vendor risk, secure software supply chain, incident response, awareness, change control en monitoring.

Sterker nog: AI maakt zwakke basisbeveiliging juist zichtbaarder. Als een aanvaller sneller kan zoeken, testen en combineren, dan worden oude fouten sneller misbruikt. Een vergeten token. Een te brede developerrol. Een extensie zonder allowlisting. Een pipeline-secret zonder rotatie. Een package zonder review. Een laptop met te veel repo-toegang. Allemaal kleine dingen die pas groot worden wanneer ze samenkomen.

Onderzoek naar 'swarm-attack' laat zien dat meerdere kleine LLM-agents met shared memory, parallel exploration en tooling samen securitytaken kunnen uitvoeren, waaronder vulnerability discovery in een testomgeving. De onderzoekers stellen dat niet alleen het model, maar vooral het systeem eromheen, de scaffold, de doorslaggevende factor is.

Dat is precies de les voor organisaties: kijk niet alleen naar 'welk AI-model is gevaarlijk?' Kijk naar systemen, naar workflows, naar rechten, naar automatisering en naar hoe makkelijk een agent, extensie of package toegang krijgt tot echte bedrijfsdata.

De Cyberbeveiligingswet maakt dit bestuurlijker dan veel organisaties denken

Dit is ook waarom de link met de Cyberbeveiligingswet en NIS2 zo belangrijk is. NIS2 draait niet alleen om technische maatregelen. Het gaat om risicobeheer, incidentmelding, governance en ketenbeveiliging. De Europese NIS2-richtlijn breidt de scope uit ten opzichte van NIS1, harmoniseert incidentmeldingen en scherpt toezicht en handhaving aan. Belangrijk is vooral dat NIS2 cybersecurity niet langer ziet als een puur IT-vraagstuk, maar als bestuurlijk risico voor essentiële en belangrijke entiteiten.

Voor Nederlandse organisaties wordt dit via de Cyberbeveiligingswet vertaald naar nationale verplichtingen. Ook als een organisatie niet direct onder de zwaarste categorie valt, wordt de norm in de markt duidelijk: bestuurders, leveranciers, IT-partners en securityteams moeten aantoonbaar nadenken over risico's in de keten.

En developer tooling is ketenrisico. Een organisatie kan haar eigen firewall op orde hebben, maar alsnog geraakt worden via een compromised package, een poisoned VS Code extension, een gecompromitteerde maintainer, een GitHub Action, een CI/CD-token, een SaaS-koppeling, een AI-code-assistent met te brede rechten of een leverancier die credentials onvoldoende segmenteert.

Daarom past de GitHub-case zo goed bij de geest van NIS2. Niet omdat NIS2 specifiek zegt 'controleer je VS Code-extensies', maar omdat de richtlijn organisaties dwingt om systematisch te kijken naar afhankelijkheden, incidentrespons, leveranciersrisico en technische én organisatorische maatregelen. Onderzoek naar NIS2-compliance benadrukt dat de richtlijn draait om risicomanagementmaatregelen voor essentiële en belangrijke entiteiten, plus evaluatie van het informatiebeveiligingsniveau.

Wat organisaties nu concreet moeten doen

De praktische vertaling is niet dat developers niets meer mogen installeren. Dat zou onrealistisch zijn en innovatie blokkeren. De vertaling is: maak developer tooling beheersbaar.

Begin met zicht. Welke extensies worden gebruikt? Welke packages zijn kritisch? Welke GitHub Actions draaien in pipelines? Welke tokens bestaan er? Welke secrets zitten in lokale omgevingen? Welke tools mogen auto-updaten? Welke AI-code-assistenten hebben toegang tot codebases?

Daarna komt beleid. Niet als pdf, maar als werkend control model: allowlisting voor IDE-extensies, minimum package age voor dependencies, dependency pinning waar nodig, strictere review voor packages met install scripts, secret scanning in repositories en endpoints, automatische tokenrotatie, device isolation bij verdachte developeractiviteit, monitoring op onverwachte repo-clones, beperkingen op persoonlijke access tokens, sterke MFA en conditional access, least privilege voor ontwikkelaars, aparte accounts voor beheer, development en productie, logging op CI/CD-activiteiten en duidelijke incidentrunbooks voor supply-chaincompromise.

Daarna komt detectie. Want voorkomen lukt niet altijd. De vraag is hoe snel je ziet dat er iets misgaat. Een poisoned extensie is gevaarlijk, maar nog gevaarlijker is een poisoned extensie die ongemerkt credentials exfiltreert en daarna wekenlang vervolgtoegang mogelijk maakt.

Dat maakt MDR en SOC-capaciteit relevant. Niet als marketingterm, maar als operationele noodzaak. Als secrets, repositories, endpoints en cloudomgevingen samenkomen, heb je correlatie nodig. Een endpoint-alert is niet genoeg. Een GitHub-alert is niet genoeg. Een cloud-alert is niet genoeg. Je wilt kunnen zien dat één verdachte extensie-installatie, één ongebruikelijke repo-access, één nieuwe tokenactie en één vreemd cloudverzoek mogelijk hetzelfde incident zijn.

Waarom goede vendoren belangrijker worden, niet minder

In een aanvalsgolf als deze heb je geen behoefte aan nog meer losse dashboards. Je hebt behoefte aan een ecosysteem dat samenwerkt.

Microsoft is relevant omdat veel organisaties bouwen op GitHub, Entra ID, Defender, Intune, Azure en Microsoft 365. Fortinet is relevant voor netwerksegmentatie, secure access, firewalling, endpoint en bredere security fabric. Trend Micro is relevant voor threat intelligence, workload security en supply-chainachtige dreigingsdetectie. Arctic Wolf is relevant voor MDR, 24/7 monitoring, triage en incidentopvolging. KnowBe4 blijft relevant omdat social engineering, credential theft en menselijke workflows nog steeds vaak de eerste schakel vormen.

Maar de vendor zelf is nooit genoeg. De waarde ontstaat pas wanneer die vendorcapaciteiten goed worden ingericht, beheerd en vertaald naar de praktijk van de organisatie. Daar zit de rol van Flowerbed.

Flowerbed helpt organisaties niet door te roepen dat er 'meer security' nodig is, maar door samen te bepalen waar de grootste risico's zitten: waar zitten de kroonjuwelen, welke developer workflows zijn kritisch, welke cloudrechten zijn te breed, welke leveranciers en tools vormen ketenrisico, welke signalen moeten gemonitord worden, welke incidentrunbooks ontbreken, welke maatregelen zijn nodig voor NIS2- en Cyberbeveiligingswet-readiness en welke technologie past bij de volwassenheid van de organisatie.

De belangrijkste les uit de GitHub-case

De les is niet dat VS Code onveilig is. De les is niet dat open source slecht is. De les is niet dat developers niets meer mogen installeren. De les is dat vertrouwen tegenwoordig uitvoerbaar is.

Een extensie is uitvoerbaar vertrouwen. Een package is uitvoerbaar vertrouwen. Een GitHub Action is uitvoerbaar vertrouwen. Een AI-agent is uitvoerbaar vertrouwen. Een dependency is uitvoerbaar vertrouwen. Een vendorintegratie is uitvoerbaar vertrouwen.

En alles wat uitvoerbaar vertrouwen krijgt, moet je kunnen zien, beperken, monitoren en intrekken. Dat is de echte verschuiving.

Wat je deze zaterdag zelf kunt checken

Omdat dit een Geeky Saturday is, eindigen we praktisch. Wil je vandaag al iets doen, check dan dit. Open je VS Code-extensies en kijk welke aan staan, welke automatisch worden geüpdatet en welke toegang hebben tot terminals, repos of credentials. Controleer je developer tokens: welke personal access tokens bestaan er nog, welke zijn te oud en welke hebben te veel scope? Kijk naar je package-locks en dependency updates: gebruik je minimum package age, worden nieuwe packageversies direct geaccepteerd? Check je CI/CD-secrets: welke secrets zijn beschikbaar in pipelines, zijn ze omgevingsspecifiek, kunnen ze worden misbruikt voor lateral movement? Controleer GitHub Actions en third-party workflows: gebruik je pinned commits of losse versies, wie mag workflows aanpassen? Test je incidentrunbook: weet je wat je doet bij een compromised developer workstation, wie roteert tokens, wie isoleert devices, wie beoordeelt repo-exfiltratie? Check je logging: kun je zien wanneer ongebruikelijke repo-access, clone-activiteit, tokengebruik of extensiegedrag plaatsvindt? Bespreek dit met je securitypartner, niet omdat alles meteen dicht moet, maar omdat dit soort risico's alleen beheersbaar worden als techniek, proces en governance samenkomen.

Onze conclusie

De GitHub-case is geen los incident. Het is een waarschuwing voor iedere organisatie die vertrouwt op developer tooling, cloudplatformen, open source, CI/CD en AI-assisted development. Aanvallers hoeven niet altijd meer door de voordeur. Soms wachten ze tot een vertrouwde tool zichzelf bijwerkt.

Daarom moet security mee veranderen. Van perimeterdenken naar ketendenken. Van alleen patchen naar monitoren en segmenteren. Van losse tooling naar managed detectie en governance. Van vertrouwen op vendorreputatie naar aantoonbaar beheer van rechten, updates, secrets en incidentrespons.

En ja, AI gaat dit versnellen. Aanvallers gebruiken AI om sneller te zoeken, te combineren en te misbruiken. Verdedigers moeten AI gebruiken om sneller te detecteren, te prioriteren en te reageren. Maar de basis blijft hetzelfde: goede infrastructuur, goede vendoren, goede governance en een securitypartner die niet alleen producten levert, maar helpt om risico's operationeel te beheersen.

Hoe kwetsbaar is jouw developer-omgeving écht?

Wil je weten hoe kwetsbaar jouw organisatie is voor supply-chainaanvallen via developer tooling, cloudtokens, AI-tools of CI/CD? Plan dan een afspraak met Flowerbed engineering. Wij helpen je om developer security, MDR, cloud governance, vendor risk en Cyberbeveiligingswet-readiness samen te brengen in één praktische aanpak.