De meeste beveiligingsverhalen in deze nieuwsbrief gaan over dingen die jou rechtstreeks overkomen: een phishing-sms, een gelekt wachtwoord, een nepwebshop. Deze is anders. De incidenten hieronder overkwamen ontwikkelaars — de mensen die de apps en diensten schrijven die je elke dag gebruikt. Maar waarom ze hier thuishoren, is eenvoudig: als iemand de tools vergiftigt waarmee software wordt gebouwd, blijft het gif niet bij de bouwer. Het wordt met het product meegeleverd.

Onlangs gebeurden er twee dingen die dit illustreren. Geen van beide haalde de krantenkoppen zoals een groot datalek dat doet, omdat geen van beide specifiek een inbreuk op jou is. Het zijn allebei aanvallen op de pijplijn die de software produceert die je uiteindelijk installeert, opent of gebruikt om in te loggen.

Vervalste extensies vermomd als vertrouwde merken

Open VSX is een openbare marktplaats voor extensies voor code-editors — de kleine uitbreidingen die ontwikkelaars installeren voor automatisch aanvullen, linting en integraties met de tools die ze dagelijks gebruiken (Visual Studio Code en verschillende van zijn opensource-nevenprojecten halen er extensies vandaan). Tussen July 26 en August 1, 2026 vonden beveiligingsonderzoekers van Manifold Security 77 vervalste extensies in het register. Elk daarvan kopieerde de naam en namespace van een echte, vertrouwde extensie, maar was gepubliceerd vanuit een account dat niet de eigenaar van het origineel was — een klassieke vorm van imitatie, soms namespace-squatting genoemd.

De gekaapte namen waren niet willekeurig. Ze leenden de identiteiten van AMD, LEGO Education, Hyperledger, Azure, Artsy, de opensourceprojecten van Salesforce, een federale instantie van de VS en — met een soort duistere ironie — de extensiemarktplaats zelf. Elk van de 77 pakketten nam contact op met één domein dat slechts 11 dagen voordat het eerste nep pakket verscheen was geregistreerd, een patroon dat wijst op een gecoördineerde, doelbewust opgezette campagne in plaats van opportunistisch kopieergedrag.

De meeste nep-extensies deden iets bescheidens: ze stuurden stilletjes een hostnaam terug naar de server van de aanvaller, wat op zichzelf misschien alleen een controle is om te zien wie het lokaas heeft geïnstalleerd. Maar onderzoekers ontdekten dat ongeveer een kwart van de 77 — 19 pakketten — verder ging. Enkele seconden na activering verzamelden ze de hostnaam, de gebruikersnaam van het besturingssysteem, gegevens over de editor en een machine-ID. Vervolgens lazen ze het project dat de ontwikkelaar open had staan: de git-remote (die de organisatie en repositoryhost onthult), het domein van het commit-e-mailadres, de huidige branch en de meest recente commit. Ze haalden ook continuous-integrationwaarden op — de inloggegevens en configuratie waarmee geautomatiseerde systemen code kunnen bouwen en implementeren zonder dat iemand telkens een wachtwoord hoeft in te typen.

Geen van die gegevens is nuttig om iemands bankrekening leeg te halen. Ze zijn nuttig voor iets anders: uitzoeken voor welke bedrijven een ontwikkelaar werkt, hoe hun interne infrastructuur eruitziet en hoe je er voet aan de grond krijgt.

Een bug met een score van 9,8 op 10 in de machine die de software bouwt

Het tweede incident betreft TeamCity, een platform voor continuous integration en continuous delivery (CI/CD) van JetBrains. Als een code-editor de plek is waar ontwikkelaars software schrijven, dan is een CI/CD-platform de geautomatiseerde fabrieksvloer waar die code wordt gecompileerd, getest en naar productie uitgerold — vaak zonder dat iemand überhaupt op 'deploy' hoeft te klikken. TeamCity is bij veel bedrijven een centraal onderdeel van die machinerie.

In de on-premisesversies van TeamCity is een kwetsbaarheid bekendgemaakt die wordt bijgehouden als CVE-2026-63077, met een ernstscore van 9,8 op een mogelijke 10. Het gaat om een deserialisatiefout — een klasse bug waarbij een programma binnenkomende gegevens voldoende vertrouwt om ze rechtstreeks om te zetten in uitvoerbare code, zonder eerst te controleren wat die gegevens daadwerkelijk zijn. In de praktijk kon een aanvaller zonder inloggen een verzoek naar een kwetsbare TeamCity-server sturen en willekeurige opdrachten uitvoeren met dezelfde rechten als de TeamCity-service zelf. JetBrains bracht patches uit (versies 2025.11.7 en 2026.1.3, plus een patchplugin voor oudere installaties vanaf 2017.1), maar de Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) heeft sindsdien gewaarschuwd dat aanvallers ongepatchte systemen actief misbruiken.

Wie de buildserver van een bedrijf beheert, bepaalt wat dat bedrijf uitbrengt. Dat is geen hypothetisch scenario — het is letterlijk de functie van de tool.

Hetzelfde draaiboek, twee verschillende deuren

Dit zijn ongerelateerde incidenten van verschillende onderzoekers, maar ze hebben dezelfde structuur. Geen van beide valt een voltooid product aan. Beide vallen een eerdere stap aan — de editor waarin een ontwikkelaar code schrijft, of de server die die code omzet in een uitgebrachte versie. Dat is het kenmerkende van een aanval op de softwaretoeleveringsketen: in plaats van één doelwit binnen te dringen, breng je iets upstream in gevaar waarvan veel doelwitten afhankelijk zijn, en laat je hun eigen vertrouwde proces je toegang voor je verder verspreiden.

We moeten eerlijk zijn over wat we nog niet weten. Geen van de rapporten die deze week naar buiten kwamen, maakte een bevestigd geval bekend waarin een downstream-app of gebruiker als rechtstreeks gevolg was gecompromitteerd — de campagne met de extensies lijkt gericht op verkenning en het verzamelen van toegang, en de exploitatie van TeamCity wordt beschreven als actief, maar zonder genoemde slachtoffers. Dat is normaal; compromitteringen van de toeleveringsketen worden vaak bij het toegangspunt ontdekt, lang voordat (of in plaats van dat) de uiteindelijke opbrengst wordt getraceerd.

Waarom dit jouw probleem is, niet alleen dat van hen

Waarschijnlijk zul je nooit een code-extensie installeren of een CI/CD-server beheren. Maar je gebruikt wel de output van honderden daarvan: je bankapp, je wachtwoordmanager, het schoolportaal van je kind, de browser waarin je dit leest. Alles is via de editor van een ontwikkelaar en de buildpijplijn van een bedrijf gegaan voordat het je telefoon bereikte. Als een van die schakels ongemerkt is gecompromitteerd, kan de kwaadaardige wijziging meeliften met een gewone, routinematige software-update — het soort update dat je installeert omdat je is verteld dat updaten het veilige is om te doen.

Daarom klinkt het advies in een postmortem van een datalek voor niet-technische lezers soms ook vreemd: een bedrijf zegt dat zijn systemen zijn gecompromitteerd via een buildserver, een gestolen inloggegeven van een ontwikkelaar of een kwaadaardige dependency, en dat kan abstract klinken naast 'iemand heeft mijn wachtwoord geraden'. Dat is het niet. Het is dezelfde uitkomst — je gegevens of de integriteit van je app is gecompromitteerd — maar bereikt via een deur waarvan je niet wist dat die bestond.

Wat echt helpt

Je kunt de CI/CD-pijplijn van je bank niet controleren, en dat zou ook niet nodig moeten zijn. Maar een paar gewoonten verkleinen je blootstelling aan dit soort risico's echt:

Houd automatische updates ingeschakeld, maar beschouw updates niet automatisch als betrouwbaar. Via patches komen oplossingen zoals die voor TeamCity hierboven terecht in de software die je gebruikt — door up-to-date te blijven, sluit je vensters die aanvallers actief proberen binnen te gaan. Tegelijkertijd is een update maar zo goed als de pijplijn die hem heeft geproduceerd, en juist die wordt hier aangevallen; er bestaat geen perfecte individuele verdediging tegen een werkelijk vergiftigde upstreamrelease. Daarom is dit fundamenteel een probleem waarvoor de leverancier verantwoordelijk is, niet jij.

Als je met ontwikkelaars werkt of hen aanstuurt, zijn er twee concrete, controleerbare dingen: controleer of elke extensie voor een code-editor is geïnstalleerd vanuit het daadwerkelijk geverifieerde uitgeversaccount, en niet alleen op basis van een overeenkomende naam (Open VSX en vergelijkbare marktplaatsen tonen de identiteit van de uitgever — controleer die; vertrouw niet alleen op het pictogram en de titel); en als je organisatie TeamCity on-premises gebruikt, controleer dan vandaag nog of het op 2025.11.7 of 2026.1.3 draait, of dat de patchplugin is toegepast — niet tijdens het volgende onderhoudsvenster. De waarschuwing van CISA betekent dat dit actief wordt misbruikt, niet dat het theoretisch is.

Voor alle anderen is de nuttige omslag eenvoudigweg bewustwording: als je leest over een bedrijfsinbreuk die terug te voeren is op 'een gecompromitteerde ontwikkelaarstool' of 'een bouwsysteem', dan is dat geen technische voetnoot voor een nichepubliek. Het is dezelfde categorie gebeurtenis als de wachtwoordlekken en phishingfraude waar deze nieuwsbrief vaker over schrijft — alleen begon het één laag verder upstream, voordat het product jou ooit bereikte.