Aanvallers in de toeleveringsketen proberen niet alleen kwaadaardige code in vertrouwde software te stoppen. Ze proberen de toegang te stelen die vertrouwde software mogelijk maakt. Onlangs bereikten drie afzonderlijke campagnes npm, PyPI en Docker Hub in een tijdsbestek van 48 uur, en alle drie waren gericht op geheimen uit ontwikkelaarsomgevingen en CI/CD-pijplijnen, waaronder API-sleutels, cloudreferenties, SSH-sleutels en tokens. Dit is een voortdurende zorg en verspreidt zich vanzelf, zoals blijkt uit aanvallen zoals de ‘mini Shai Hulud’-campagnes.
Dat patroon zou de manier moeten veranderen waarop beveiligingsteams over de softwaretoeleveringsketen denken.
Traditioneel was beveiliging gericht op gedeelde systemen zoals broncodeopslagplaatsen, CI/CD-platforms, artefactregisters, pakketbeheerders en cloudomgevingen. Het doel was om productieworkloads en gegevens te beschermen. We moeten ons absoluut nog steeds op deze gebieden concentreren, maar het is een onvolledig beeld.
De levering van moderne software begint voordat de code Git bereikt. Het begint op het ontwikkelaarswerkstation, waar code wordt geschreven, afhankelijkheden worden geïnstalleerd, inloggegevens worden getest, AI-assistenten worden gevraagd, containers worden gebouwd en vertrouwde acties beginnen.
Werkstations voor ontwikkelaars vormen een reëel onderdeel van de softwaretoeleveringsketen. Door ze te behandelen als ‘slechts’ gewone eindpunten ontstaan gaten tussen de eindpuntbeveiliging, identiteitsbeveiliging, applicatiebeveiliging en supply chain governance.
Supply Chain-aanvallen zijn het verzamelen van inloggegevens geworden
Recente incidenten wijzen steeds op dezelfde operationele waarheid. Aanvallers kunnen vergiftigde pakketten, gecompromitteerde afbeeldingen, afhankelijkheidsbots, kwaadaardige workflows of kwetsbare ontwikkelaarstools gebruiken, maar het terugkerende doel is toegang.
Gebeurtenissen als de TeamPCP- en Shai-Hulud-campagnes laten zien hoe supply chain-aanvallen steeds meer samenkomen rond diefstal van inloggegevens. In de TeamPCP-campagne gebruikten aanvallers gecompromitteerde pakketten en ontwikkelaarstools om tokens, cloudreferenties, SSH-sleutels, npm-configuratiebestanden en omgevingsvariabelen te verzamelen.
Shai-Hulud duwde hetzelfde patroon nog verder door geïnfecteerde ontwikkelaarsomgevingen te veranderen in verzamelpunten voor inloggegevens die duizenden geheimen blootlegden op GitHub, cloudservices, pakketregisters en interne systemen.
Dat is niet alleen geknoei met software. Het is het verzamelen van inloggegevens op de punten waar ontwikkelaars en automatisering al vertrouwen hebben.
De toeleveringsketen wordt blootgelegd wanneer aanvallers toegang krijgen tot inloggegevens en context waarmee ze vertrouwde softwaresystemen kunnen wijzigen, publiceren, bouwen, implementeren of nabootsen. Pakketten die tijdens een moderne supply chain-aanval zijn gewijzigd en gepubliceerd, blijven urenlang live, terwijl automatiseringstools kwaadaardige updates binnen enkele minuten samenvoegen.
De rode draad bij veel van de recente aanvallen zijn geheimen geweest, hetzij als initiële toegangsvector, hetzij als doelwit voor verzameling.
Het pad van de aanvaller loopt nu via de context aan de ontwikkelaarskant
Het ontwikkelaarswerkstation is waardevol omdat het de context concentreert. Het bevat vaak lokale opslagplaatsen, .env-bestanden, shell-geschiedenis, SSH-sleutels, inloggegevens en configuraties van pakketbeheerders, build-scripts, foutopsporingslogboeken en browsersessies. Die stukken worden veel gevaarlijker als ze samen worden bekeken.
Eén enkel toegangstoken kan op zichzelf beperkt lijken. Een token dat naast een Git-afstandsbediening, implementatiescript, README, cloudprofiel en CI-configuratie wordt gevonden, vertelt een aanvaller waar het token past en wat het zou kunnen ontgrendelen. In de Shai-Hulud 2.0-campagne domineerden GitHub-referenties bijvoorbeeld de blootgestelde en geëxfiltreerde inloggegevens, elk met potentiële beheerderstoegang tot opslagplaatsen en CI-workflows.
Lokaal compromis is niet alleen een apparaatprobleem. Het kan dienen als een kaart voor bronbeheer, cloudaccounts, workflows voor het publiceren van pakketten, CI/CD-systemen, interne API’s en productie-aangrenzende infrastructuur.
Ontwikkelmachines concentreren zich op softwareleveringsautoriteit
Een standaard werknemerslaptop kan bedrijfsgegevens blootleggen. Een ontwikkelaarswerkstation kan de mogelijkheid bieden om software te wijzigen. Dat onderscheid is van cruciaal belang bij het overwegen van eindpuntbeveiliging.
Ontwikkelaars hebben vaak behoefte aan brede toegang om hun werk te kunnen doen. Ze klonen privéopslagplaatsen, authenticeren zich bij cloudservices, publiceren pakketten, hebben toegang tot stagingomgevingen en communiceren met meerdere interne tools. Hun machines worden een werkende kruising van broncode, inloggegevens, automatisering en leveringsautoriteit.
Hoewel niet elke ontwikkelaar productietoegang heeft, hebben velen wel voldoende toegang om de systemen te beïnvloeden die uiteindelijk productieresultaten opleveren. Een registertoken kan van invloed zijn op pakketten. Een GitHub-token kan opslagplaatsen of werkstromen beïnvloeden. Een cloudprofiel kan infrastructuur blootleggen. Een CI/CD-referentie kan het buildgedrag beïnvloeden.
Het maakt het bestuur en de auditors niet uit of een ontwikkelaar een geheim lokaal heeft opgeslagen. Het bedrijfsrisico is eigenlijk dat een lokale blootstelling aanvallers een pad geeft naar systemen die software bouwen, wijzigen, vrijgeven of bedienen.
Deze verschuiving verandert de vragen die beveiligingsteams moeten stellen:
- Kunt u identificeren welke inloggegevens bruikbaar zijn vanaf werkstations voor ontwikkelaars?
- Kunt u de waarde en levensduur van deze inloggegevens beperken?
- Kun je gevoelig materiaal detecteren voordat het in de Git-geschiedenis, CI-logboeken, tickets, artefacten of chat terechtkomt?
- Kunt u de toegang snel intrekken en rouleren als u vermoedt dat er sprake is van een inbreuk op uw werkstation?
- Kunt u het verschil zien tussen lokale blootstelling met een lage impact en inloggegevens met beheerdersrechten?
Deze vragen bevinden zich tussen AppSec, eindpunt, identiteit, platform en cloudbeveiliging. Hoe uw organisatie ook kiest voor coördinatie, u moet begrijpen hoe het gedrag van ontwikkelaars verband houdt met leveringssystemen.
Automatisering en AI maken het belichtingsoppervlak dunner en sneller
Automatisering heeft de tijd tussen compromissen en impact gecomprimeerd. Afhankelijkheidsupdatebots kunnen wijzigingen snel openen en samenvoegen. CI/CD-systemen kunnen vertrouwde workflows automatisch uitvoeren. Pakketbeheerders kunnen installatiescripts uitvoeren. AI-agenten en codeerassistenten kunnen bestanden lezen, tools aanroepen, opdrachten genereren, uitvoer inspecteren en context tussen systemen verplaatsen.
Automatisering is niet per definitie onveilig, maar normaal gesproken erft elke automatisering vertrouwen, vooral als deze in een agentische vorm wordt geleverd. Als een kwaadwillige afhankelijkheidsupdate routine lijkt, kan een geautomatiseerde workflow deze sneller vooruit helpen dan een menselijke recensent kan begrijpen wat er is gebeurd.
AI in de lus
Door AI ondersteunde ontwikkeling voegt nog een reeks overdrachtspunten toe. Gevoelige gegevens kunnen verschijnen in aanwijzingen, terminaluitvoer, tooloproepen, gegenereerde code, agentgeheugen, logboeken en lokale configuratie die naar een foutopsporingssessie zijn gekopieerd. Het probleem is breder dan de vraag of een modelaanbieder aanwijzingen opslaat. Het grotere probleem is dat de lokale ontwikkelingscontext nu via meer semi-geautomatiseerde systemen stroomt.
Beveiligingsteams moeten het risico op AI-codering beoordelen door dezelfde lens die zij gebruiken voor het risico van de toeleveringsketen. Teams moeten antwoorden: welke bronnen en gegevens kan de tool lezen? Wat kan het uitvoeren? Waar gaat de output naartoe? Welke referenties zijn in de buurt? En misschien wel het allerbelangrijkste: welk vertrouwen erft de workflow?
Controles verderop in de keten zijn nog steeds belangrijk, maar zijn op zichzelf al te laat
Het scannen van opslagplaatsen, vertakkingsbescherming, CI/CD-beleid, het ondertekenen van artefacten, afhankelijkheidsanalyse en runtime-controles blijven essentieel. Ze creëren gedeelde handhavingspunten en helpen teams software op schaal te beheren.
Het probleem komt nu op het juiste moment, dankzij de snelheid van moderne aanvallen. Aanvallers maken nu gebruik van door AI aangedreven tools om alle geheimen binnen enkele seconden na ontdekking te misbruiken.
Vangrails verminderen de potentiële blootstelling en de explosieradius. Het onderscheppen van gevoelig materiaal terwijl een ontwikkelaar een bestand bewerkt, een commit voorbereidt, een lokale opdracht uitvoert, een afhankelijkheid installeert of interactie heeft met een AI-assistent, houdt de impact tot een minimum beperkt.
Volwassen programma’s maken onderscheid tussen acties die moeten worden geblokkeerd, acties die waarschuwingen moeten geven en acties die alleen maar telemetrie moeten genereren voor diepgaander onderzoek. Het doel is niet om ontwikkelaars in wrijving te begraven.
Behandel het werkstation als de grens van de lokale toeleveringsketen
De moderne software-toeleveringsketen begint niet wanneer code wordt gepusht. Het begint waar code, inloggegevens, automatisering en vertrouwen voor het eerst samenkomen.
Het is tijd om het ontwikkelaarswerkstation te beschouwen als de grens van de lokale toeleveringsketen. Die grens omvat de IDE, terminal, Git-client, pakketbeheerder, containertooling, cloud-CLI, lokaal bouwsysteem, praktijken voor het verwerken van geheimen, AI-assistenten en automatiseringsagenten. Het is de plaats waar de actie van individuele ontwikkelaars een risico voor de levering van software voor de organisatie wordt.
