Supply Chain Attacks in AI: Wat recente incidenten onthullen over AI-infrastructuurbeveiliging

Op 24 maart 2026 was een onderzoeker voor FutureSearch bezig met een routinetaak. De taak was het installeren van een Python-package voor een project. Binnen enkele minuten begon het werkstation zich grillig te gedragen. 

Het geheugengebruik nam aanzienlijk toe. Er verschenen onbekende processen. Het systeem crashte. De onderzoeker had onwetend een van de meest geavanceerde software supply chain attacks ontketend die ooit tegen het AI-ecosysteem is uitgevoerd. Deze aanval was al maanden actief en besmette duizenden ontwikkelaarsomgevingen voordat iemand de aanwezigheid ervan publiekelijk herkende. 

Dit artikel zal de gebeurtenissen onderzoeken die plaatsvonden en uitleggen waarom AI-tooling bijzonder kwetsbaar is voor dit soort aanvallen. Het zal ook bespreken hoe engineeringteams zichzelf kunnen beschermen.

Wat er gebeurde: Een Supply Chain Attack drie stappen diep

De dreigingsactor die is geïdentificeerd als "TeamPCP", actief sinds ten minste december 2025 en door onderzoekers van Wiz gevolgd door negen fasen van deze voortdurende aanval, richtte zich niet rechtstreeks op hun uiteindelijke doel. In plaats daarvan voerde deze dreigingsactor een zorgvuldige, meerfasige supply chain attack uit.

Stap 1: Op 19 maart compromisede TeamPCP Trivy, een veelgebruikte open-source beveiligingsscanner die is geïntegreerd in de CI/CD-pipelines van vele projecten.

Stap 2: Met behulp van die houvast verkregen ze de PyPI-publicatiegegevens van een beheerder van een populaire LLM-proxy-bibliotheek die ongeveer 3,4 miljoen keer per dag wordt gedownload.

Stap 3: Op 24 maart uploadden ze twee kwaadaardige versies van het package naar PyPI. De gecompromitteerde versies stonden ongeveer drie uur live voordat PyPI ze in quarantaine plaatste.

Dit is het bepalende kenmerk van moderne supply chain attacks: de aanvaller hoeft u nooit rechtstreeks te hacken. Ze dringen binnen bij iemand die uw tools vertrouwen, en laten dat vertrouwen hen de rest van de weg dragen.

Binnenin de Payload: Drie fasen van besmetting

Het kwaadaardige package voerde een geavanceerde payload in drie fasen uit, die beveiligingsonderzoekers van Snyk gedetailleerd hebben gedocumenteerd.

Fase 1 — Informatieverzameling. De payload verzamelde in stilte alles wat hij kon vinden: SSH-prive-sleutels, AWS- en GCP-toegangsgegevens, Azure-service principals, Kubernetes-configuraties, .env-bestanden, git-referenties, database-wachtwoorden, shell-historie, CI/CD-geheimen en seed-phrases van cryptocurrency-wallets.

Fase 2 — Encryptie en exfiltratie. Verzafelde gegevens werden versleuteld en verzonden naar een server onder controle van de aanvaller. Tijdelijke bestanden (session.key, payload.enc, tpcp.tar.gz) werden tijdens dit proces aangemaakt in de tijdelijke systeemmaap.

Fase 3 — Persistentie en laterale verplaatsing. De payload installeerde een backdoor-Python-script vermomd als een systemd-service genaamd "System Telemetry Service". Dit persistentiescript raadpleegde elke vijf minuten een door de aanvaller beheerde URL voor nieuwe commando's — en was in staat om zich te verspreiden over uw gehele Kubernetes-cluster door geprivilegieerde pods uit te rollen naar elke node in kube-system.

Wat dit bijzonder gevaarlijk maakte, was het aflevermechanisme: een .pth-bestand. Python-padconfiguratiebestanden worden automatisch uitgevoerd zodra er een Python-proces start — inclusief pip zelf, inclusief CI/CD-bouwstappen, inclusief test-runners. U hoefde uw applicatie niet eens uit te voeren. U hoefde alleen maar het package te hebben geïnstalleerd, en de payload werd uitgevoerd.

Waarom AI-infrastructuur een speciaal doelwit is

Het package dat werd getroffen, was niet willekeurig gekozen. Een van de meest geprivilegieerde posities in de moderne softwarestack is die van Large Language Model (LLM) proxies en AI gateways. Wanneer u een LLM gateway installeert en instelt, plaatst u deze direct tussen applicaties en de AI-serviceproviders die worden gebruikt. Het heeft toegang tot OpenAI API-sleutels, Anthropic-referenties, Azure- en Google Cloud Platform-serviceaccounts. Het heeft toegang tot omgevingsvariabelen en, in veel gevallen, de secrets manager. Dit is zo ontworpen en is noodzakelijk om verzoeken te routeren, limieten af te dwingen en gebruik te loggen. Dit is het beoogde gedrag.

Dit betekent ook dat als de LLM gateway en/of een van de afhankelijkheden (dependencies) ervan gecompromitteerd zijn, de aanvaller volledig zicht heeft op de AI-infrastructuur. Sonatype-onderzoekers schreven in hun rapport over dit incident: “Omdat LiteLLM zich doorgaans rechtstreeks tussen applicaties en meerdere AI-serviceproviders bevindt, heeft het vaak toegang tot API-sleutels, omgevingsvariabelen en andere gevoelige configuratiegegevens. Het compromitteren van een package in deze positie stelt aanvallers in staat om waardevolle geheimen te onderscheppen en te exfiltreren zonder dat ze upstream-systemen rechtstreeks hoeven te hacken.”

Waarom compliance-kaders het niet opmerkten

Het betrokken package beschikte over SOC 2 Type 1- en ISO 27001-certificeringen. Dit is waardevol om te onderzoeken, niet om die kaders te bekritiseren — ze doen er toe, en teams die ze nastreven doen het juiste — maar omdat het een structurele kloof illustreert.

Compliance-kaders controleren wat u doet aan de hand van een checklist. Ze behandelen toegangsbeheer, gegevensverwerking en incidentrespons. Ze onderzoeken doorgaans niet of de beveiligingsscanner in uw CI/CD-pipeline gecompromitteerd is door een dreigingsactor die vervolgens uw PyPI-publicatiegegevens heeft gestolen.

Zelfs standaard pip-hash-verificatie zou deze aanval niet hebben opgemerkt. Het kwaadaardige .pth-bestand in de gecompromitteerde versie was correct verklaard in het RECORD-bestand van het package met een overeenkomende hash. Het package slaagde voor elke integriteitscontrole die PyPI biedt. Het was een geldig package dat toevallig als wapen was ingezet.

Dit is de kloof in supply chain security die het AI-ecosysteem specifiek moet dichten: de vraag is niet alleen "zijn onze systemen veilig?" Het is "zijn de tools die we gebruiken om onze systemen te bouwen en te beveiligen veilig?"

Belangrijke meetstatistieken voor het evalueren van een gateway

Criterium	Wat moet u evalueren?	Prioriteit	TrueFoundry
Latency	Voegt <10ms p95 overhead toe voor time-to-first-token?	Must Have	✅ Ondersteund
Dataresidentie	Houdt logs binnen uw regio (EU/US)?	Afhankelijk van use case	✅ Ondersteund
Latency-gebaseerde routing	Stuurt automatisch om op basis van realtime latency/storingen?	Must Have	✅ Ondersteund
Sleutelrotatie & -intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & -intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & -intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & -intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & -intrekking	Sleutels roteren of intrekken zonder downtime?	Must Have	✅ Ondersteund

Een AI Gateway evalueren?

Een praktische gids gebruikt door platform- & infra-teams

Bedankt! Uw inzending is ontvangen!

Oeps! Er is iets misgegaan bij het verzenden van het formulier.

Hoe TrueFoundry over dit probleem denkt

Bij TrueFoundry is supply chain security een prioriteit van de eerste orde in hoe we ons MLOps-platform ontwerpen — geen bijgedachte.

Wanneer ondernemingen modellen en LLM gateways uitrollen via TrueFoundry, stellen we een ander soort vraag: niet alleen "is dit endpoint veilig?", maar "wat is de schadeomvang (blast radius) als een onderdeel in deze stack gecompromitteerd raakt?"

Een paar principes vormen de basis van wat we bouwen:

Infrastructuur draait in uw VPC. Wanneer uw AI-infrastructuur binnen uw eigen cloudgrenzen draait, reizen geheimen nooit naar externe systemen. Zelfs als een afhankelijkheid ergens in het ecosysteem gecompromitteerd zou raken, zou het exfiltratie-endpoint niet bereikbaar zijn van binnen uw netwerkperimeter.

Afhankelijkheden zijn vastgezet (pinned) en gecontroleerd. In plaats van stilzwijgend de nieuwste versie op te halen bij elke build, onderhoudt TrueFoundry vastgezette, beoordeelde afhankelijkheden over de gehele platformstack. Dit elimineert een hele klasse van supply chain-vectoren.

Componentisolatie beperkt de blast radius. Een besmetting in één laag van de stack geeft niet automatisch toegang tot een andere. Het principe van de minste privileges, afgedwongen op infrastructuurniveau.

Niets hiervan is exotherische engineering. Het is discipline toegepast op een dreigingsmodel dat AI-tooling, als industrie, niet serieus genoeg heeft genomen: de dreiging komt niet door uw firewall. Het komt door uw requirements.txt.

Wat uw team nu meteen zou moeten doen

Als u op Python gebaseerde AI-tooling gebruikt, en vrijwel elk team dat bouwt op LLM's doet dat, is het de moeite waard om de volgende acties onmiddellijk prioriteit te geven.

1. Controleer uw geïnstalleerde package-versies. Voer pip show litellm | grep Version uit. Als uw uitvoer 1.82.7 of 1.82.8 toont, behandel het systeem dan als gecompromitteerd en voer niet simpelweg een in-place upgrade uit. De payload kan al zijn uitgevoerd. Herbouw vanaf een schone staat op een gegarandeerd schone machine.

2. Controleer .pth-bestanden op machines en CI-runners.

3. Controleer op persistentie-artefacten.

4. Roteer inloggegevens agressief. Als een getroffen machine toegang had tot cloudreferenties, SSH-sleutels, API-sleutels, Kubernetes-serviceaccount-tokens of database-wachtwoorden, roteer ze dan nu allemaal. Ga niet beoordelen — roteer direct. De payload richtte zich specifiek op AWS Secrets Manager, SSM Parameter Store en Kubernetes-clustergeheimen over alle namespaces heen.

5. Controleer Kubernetes op kwaadaardige pods.

Pods genaamd node-setup-{node_name} in de kube-system namespace zijn een bekende indicator van besmetting uit deze campagne.

6. Stap over op een private package registry. PyPI is niet de enige optie voor afhankelijkheidsresolutie. Een private package-mirror met vastgezette hashes en een goedkeuringsworkflow elimineert deze gehele klasse van aanvalsvectoren. Tools zoals Artifactory, AWS CodeArtifact of Google Artifact Registry kunnen dienen als tussenpersoon.

7. Behandel uw CI/CD-supply chain als aanvalsoppervlak. De initiële besmetting in de TeamPCP-campagne was niet van de doelbibliotheek — het was van de beveiligingsscanner die werd gebruikt in de CI-pipeline van die bibliotheek. Uw bouwinfrastructuur, uw GitHub Actions en uw integraties van derden maken allemaal deel uit van uw aanvalsoppervlak. Controleer ze dienovereenkomstig.

Het bredere patroon: Dit staat niet op zichzelf

Wat deze instantie bijzonder interessant maakt, is dat het geen opportunistische aanval was. In plaats daarvan voert TeamPCP deze diepgaande campagne al uit sinds ten minste december 2025. Voordat LiteLLM werd aangevallen, compromisede TeamPCP Aqua’s Trivy beveiligingsscanner (19 maart), CheckMarx’s VS Code-extensies en GitHub Actions (23 maart), en meerdere NPM-packages die een zelfverspreidende worm bevatten.

Merk op dat het gebruikte RSA-sleutelpaar identiek is aan dat wat in alle andere aanvallen is gebruikt, evenals de naam van de tpcp.tar.gz-bundel en de met tpcp-docs geprefixte GitHub-repos. Dit suggereert dat TeamPCP een professionele dreigingsactor is die zijn campagne methodisch uitvoert.

De implicatie hier is dat de teams die door deze campagne zijn gecompromitteerd, niet nalatig waren. In plaats daarvan pasten ze best practices toe: het benutten van zeer populaire en goed beoordeelde open-source software.

Dus wat dit interessant maakt, is dat TeamPCP geen zwakheid heeft geïdentificeerd in de verdediging van één enkele organisatie. In plaats daarvan heeft TeamPCP een zwakheid geïdentificeerd in de manier waarop het bredere AI-ecosysteem omgaat met vertrouwen binnen de afhankelijkheidsketen.

Het vertrouwensprobleem dat AI-infrastructuur moet oplossen

Het AI-ecosysteem heeft in zeer korte tijd iets buitengewoons opgebouwd. De snelheid en openheid die dat mogelijk maakten — de cultuur van pip install en delen, van voortbouwen op elkaars werk is oprecht waardevol en het bewaren waard.

Maar snelheid zonder supply chain security creëert schuld. Het aanvalsoppervlak van een moderne AI-stack is niet langer alleen de endpoints die u blootstelt. Het is elk package in uw afhankelijkheidsboom, elke tool in uw CI/CD-pipeline, elk open-source component dat toegang heeft tot uw geheimen tijdens het bouwen of uitvoeren.

Het dichten van deze kloof vereist meer dan een betere incidentrespons van getroffen teams. Het vereist dat het gehele AI-infrastructuurecosysteem — beheerders, platformleveranciers, ondernemingen en beveiligingsteams — de herkomst van de supply chain (provenance) behandelt als een engineeringvraagstuk van de eerste orde.

De onderzoeker wiens machine crashte, dacht waarschijnlijk niet dat hij op het punt stond een maandenlange campagne gericht op AI-infrastructuur te onthullen. Geen van de ontwikkelaars die een routineuze pip install uitvoerden dacht dat. Dat is de aard van software supply chain attacks. Tegen de tijd dat u ze ziet, is de schade vaak al aangericht.

De AI-industrie kan beter bouwen. En dat moet ook.

Veelgestelde vragen 

Wat is een software supply chain attack?

Een software supply chain attack doet zich voor wanneer een dreigingsactor een vertrouwd component upstream van het uiteindelijke doelwit compromised — zoals een ontwikkelaarstool, open-source bibliotheek of CI/CD-pipeline — en dit gebruikt om kwaadaardige code te verspreiden naar elke downstream gebruiker van dat component. In plaats van een organisatie rechtstreeks aan te vallen, misbruiken aanvallers het impliciete vertrouwen dat ontwikkelaars stellen in veelgebruikte packages en tooling. 

Hoe kunnen AI- en ML-teams hun infrastructuur beschermen tegen supply chain attacks?

Het beschermen van AI- en ML-infrastructuur tegen supply chain attacks vereist verschillende aanvullende maatregelen. Teams moeten een private package registry gebruiken (zoals AWS CodeArtifact, Google Artifact Registry of Artifactory) met vastgezette afhankelijkheidshashes in plaats van rechtstreeks te downloaden van de openbare PyPI. Het regelmatig controleren van .pth-bestanden in Python site-packages-mappen kan kwaadaardige toevoegingen vroegtijdig aan het licht brengen. Het laten draaien van AI-infrastructuur — inclusief LLM gateways en model-serving componenten — binnen een private VPC beperkt de mogelijkheid van een aanvaller om inloggegevens te exfiltreren naar externe servers, zelfs als een afhankelijkheid gecompromitteerd is. Het onderhouden van een Software Bill of Materials (SBOM) voor uw ML-stack maakt een snellere identificatie van blootstelling mogelijk wanneer een nieuw incident bekend wordt gemaakt. Ten slotte moeten CI/CD-pipelines zelf worden behandeld als aanvalsoppervlak: de tools die worden gebruikt om software te bouwen en te beveiligen — inclusief beveiligingsscanners en GitHub Actions — kunnen gecompromitteerd worden en zijn dat ook geweest als onderdeel van bredere supply chain-campagnes.

Welke factoren moeten teams in overweging nemen bij het evalueren van een veilige LLM gateway om de risico's van supply chain attacks te beperken?

De LLM gateway moet functioneren in de VPC van de organisatie. Op deze manier zijn er geen exfiltratieroutes als de afhankelijkheden gecompromitteerd zijn. De afhankelijkheden moeten worden vastgezet en gecontroleerd in plaats van te worden opgelost tijdens de installatie met behulp van openbare registries. Inloggegevens mogen niet worden beheerd via omgevingsvariabelen, maar moeten in plaats daarvan worden beheerd via de systeemeigen secrets manager van de cloudprovider. Audit-logging van alle modelaanroepen, sleutelgebruik en configuratiewijzigingen moet ook worden uitgevoerd. Op deze manier kan abnormaal gedrag eenvoudig worden geïdentificeerd. TrueFoundry heeft al deze configuraties standaard ingesteld, waardoor het aanvalsoppervlak wordt verkleind in vergelijking met zelfbeheerde open-source tools.