Je AI-automatiseringsstack beveiligen tegen supply chain-aanvallen: van npm tot Langflow

Je hebt in een paar maanden een serieuze AI-stack opgebouwd. Een automatiseringsplatform als n8n, een gateway als LiteLLM die je modellen routeert, misschien Langflow om je flows in elkaar te klikken, en daaronder tientallen npm- en pip-pakketten en Docker-images die je nooit zelf hebt geschreven. Dat is precies het zwakke punt: het grootste deel van wat jij "mijn AI-stack" noemt, is code van vreemden. Elke extra tool, plugin of pakket vergroot je aanvalsoppervlak, en bij een supply chain-aanval hoeft een aanvaller niet bij jou in te breken. Hij vergiftigt iets dat jij zelf binnenhaalt.

Dat is geen theorie meer. De npm-scope van het Mastra-framework werd gekaapt, waarna ruim 140 pakketten voor AI-agenten een credential-steler ingespoten kregen. De kritieke Langflow-kwetsbaarheid CVE-2026-5027 wordt actief misbruikt, en in LiteLLM geven drie lekken gewone gebruikers admin-rechten en code-uitvoering. De rode draad: de kwetsbaarheid zit niet in jouw code, maar in wat eronder draait.

Deze gids is voor de ondernemer of het team dat AI-automatisering draait, zelf gehost of in eigen beheer, en wil dat een vergiftigd pakket of een gekaapte maintainer niet meteen de sleutels van het koninkrijk meegeeft. Geen abstracte securitypraat: concrete stappen die je vandaag op je eigen stack zet.

Wat je nodig hebt

• Toegang tot de plek waar je stack draait: je eigen repositories (Git), je servers of containers, en de package managers die je gebruikt (npm, pip, Docker).
• Een terminal en het recht om lockfiles te committen en images opnieuw te bouwen.
• Ongeveer een halve dag voor de basis (inventaris, pinnen, scripts uitzetten) en daarna doorlopend, deels geautomatiseerd onderhoud.
• Handig maar niet verplicht: een CI/CD-pijplijn (GitHub Actions, GitLab CI) waarin je de controles automatisch laat draaien, plus open-source gereedschap als Syft, Trivy of Grype, pip-audit en een update-bot als Renovate of Dependabot.

Je hoeft niet alles tegelijk te doen. De stappen staan op volgorde van impact: stap 1 tot en met 3 dichten het grootste gat, de rest maakt het volwassen.

De stappen: van blind vertrouwen naar gecontroleerde afhankelijkheden

Het doel is een stack waarin niets ongezien binnenkomt. Je legt elke externe afhankelijkheid vast op een exacte, geverifieerde versie, zet automatische code-uitvoering bij installatie uit, en laat een scanner en een update-bot het bewaken. Zo wordt een vergiftigd pakket een geblokkeerde build in plaats van een datalek. Werk de stappen in deze volgorde af.

1. Maak je afhankelijkheden zichtbaar

Je kunt niets beveiligen wat je niet ziet. Begin met een complete lijst van wat er echt in je stack zit, inclusief de afhankelijkheden van je afhankelijkheden (de transitieve laag, waar de meeste rommel binnenkomt). Genereer een SBOM (Software Bill of Materials, een complete stuklijst van je software) met een tool als Syft: syft dir:. -o cyclonedx-json voor je projectmap, of syft <image> voor een Docker-image. Voor een snelle blik volstaat npm ls --all en pip freeze. Bewaar die lijst, want hij is je nulmeting: wijkt de productie-stack er straks van af, dan weet je dat er iets is veranderd.

2. Pin alles vast tot op de hash

Een versienummer als ^1.2.0 betekent "1.2.0 of iets nieuwers", en dat "iets nieuwers" kan een gekaapte versie zijn. Vastpinnen sluit dat gat.

• npm: commit je package-lock.json en installeer in productie en CI met npm ci. Anders dan npm install werkt dat commando puur vanaf de lockfile en stopt het met een foutmelding als lockfile en package.json niet overeenkomen, in plaats van stilletjes iets nieuws te trekken.
• pip: werk met een lockfile vol hashes (via pip-compile --generate-hashes of uv lock) en installeer met hash-controle. Zodra je met de vlag --require-hashes installeert, weigert pip elk pakket waarvan de SHA256 niet exact klopt, dus een omgewisselde wheel faalt meteen.
• Docker: pin je base-image op zijn digest, niet op een tag. Schrijf FROM alpine:3.21@sha256:... in plaats van FROM alpine:latest. Een digest-pin garandeert dat je dezelfde image blijft gebruiken, ook als de uitgever de tag vervangt door een nieuwe image.

3. Zet code-uitvoering bij installatie uit

Dit is de stap die het vaakst wordt overgeslagen en die de meeste pijn voorkomt. Veel npm-pakketten draaien een postinstall- of preinstall-script zodra je ze installeert, en dat is precies waar de moderne supply chain-worm op mikt: het draait nog vóór jij iets gebruikt. De self-replicerende npm-worm Shai-Hulud scant bij installatie je omgeving op npm-tokens uit .npmrc, omgevingsvariabelen en cloud-credentials voor AWS, GCP en Azure, steelt ze en gebruikt jouw npm-token om zichzelf in jouw andere pakketten te publiceren.

Zet die scripts daarom standaard uit: npm config set ignore-scripts true, of per build npm ci --ignore-scripts. Een handvol pakketten heeft een legitiem buildscript nodig (denk aan esbuild); zet die op een korte, expliciete allowlist en draai hun script bewust, in plaats van de deur voor alles open te laten staan.

4. Verifieer herkomst en handtekening

Pinnen zegt "altijd dit pakket", verifiëren zegt "en het komt aantoonbaar van de echte maker". Npm publiceert tegenwoordig provenance-attestaties via Sigstore; met cosign kun je die handtekeningen en attestaties controleren voordat je iets vertrouwt. Voor je eigen images is de andere kant net zo belangrijk: onderteken wat je zelf bouwt met cosign sign, zodat je later kunt bewijzen dat een image in productie echt uit jouw pijplijn komt en niet ergens onderweg is omgewisseld. Voor het MKB is dit de stap die je gefaseerd invoert: begin met verifiëren van je belangrijkste images, niet met alles tegelijk.

5. Scan continu en automatiseer je updates

Pinnen zonder updaten ruilt het ene risico (een verrassende versie) in voor het andere (maandenlang op een lek blijven zitten). De uitweg is automatiseren met een mens aan de knoppen.

• Scannen: draai npm audit en pip-audit op je code, en Trivy of Grype op je images. Laat dit in CI draaien en laat de build falen bij een kritiek lek, zodat een kwetsbare image nooit productie haalt.
• Updaten: zet Renovate of Dependabot aan. Renovate is open source en opent automatisch pull requests om je afhankelijkheden en lockfiles bij te werken, die jij beoordeelt voor je ze mergt. Zo blijf je actueel zonder blind elke nacht nieuwe code binnen te trekken.

Dat dit collectief urgenter wordt, zie je aan de industrie zelf: Chainguard bouwt met Athena een coalitie die met AI open-source-lekken vindt vóór de aanvallers.

6. Knijp Langflow en LiteLLM dicht

De pakketten zijn nu schoon, maar de tools zelf draaien ook nog. Een gateway of flow-builder die open op het internet staat, is een uitnodiging. Het patroon is least privilege: zet authenticatie aan, schakel anonieme toegang en elke "voer willekeurige code uit"-functie uit, draai de container als non-root, en beperk uitgaand netwerkverkeer tot wat de tool echt nodig heeft. Houd je secrets buiten de omgeving van de tool zelf, want dat is precies wat een steler als eerste leegtrekt. De volledige werkwijze om een zelfgehoste AI-gateway te hardenen van standaardinstellingen naar productie-veilig staat los uitgewerkt; combineer die met het audit-ready houden van je AI-agents via logging, budgetten en kill-switches.

7. Oefen het ergste scenario

Een verdediging die je nooit test, werkt op het verkeerde moment niet. Bouw een wegwerp-omgeving en speel de aanval na: voeg een onschuldig testpakket toe met een postinstall-script dat alleen een regel naar een logbestand schrijft, en kijk of je ignore-scripts-instelling dat tegenhoudt. Stop een bewust kwetsbare versie in je requirements en controleer of je scanner de build laat falen. Loop één keer de credential-rotatie door: stel dat een token toch lekt, hoe snel kun je je npm-, GitHub- en cloud-sleutels intrekken en vervangen? Dat half uur oefenen is het verschil tussen een incident en een ramp.

Valkuilen

• Pinnen en dan nooit meer kijken. Vastgepinde versies verouderen; zonder een update-bot zit je straks vol bekende lekken. Pinnen en automatisch bijwerken horen bij elkaar.
• Alleen je directe afhankelijkheden controleren. De meeste vergiftigde pakketten zitten een of twee lagen dieper. Je SBOM en je lockfile moeten de hele boom dekken, niet alleen wat in je package.json staat.
• Secrets binnen handbereik van de tools laten slingeren. Een credential-steler pakt als eerste .npmrc, omgevingsvariabelen en cloud-tokens. Zet sleutels in een aparte secrets-laag en geef elke tool alleen wat hij nodig heeft; zo voorkom je dat één lek meteen al je API-sleutels meegeeft aan een plugin of pakket.
• ignore-scripts aanzetten en je build breken. Een paar pakketten hebben hun buildscript echt nodig. Niet in paniek alles weer aanzetten, maar een korte allowlist maken voor de uitzonderingen.
• Blind vertrouwen op één scanner. Geen enkele tool vindt alles. Combineer een dependency-audit met een image-scan en een digest-pin; de lagen vangen verschillende soorten rommel.

Kant-en-klaar vs. maatwerk

Je hoeft dit niet allemaal zelf te bouwen, maar volledig uitbesteden bestaat ook niet: supply chain-beveiliging is grotendeels configuratie en discipline in je eigen pijplijn. Een eerlijke afweging:

Voor de meeste MKB-stacks is de winnende combinatie nuchter: zet de gratis ingebouwde laag aan, voeg open-source scanning en pinnen in je CI toe, en koop pas een platform of gehardende images bij als je schaal of je compliance-eisen daarom vragen. Begin niet met het duurste gereedschap; begin met de stappen die het gat dichten.

Tot slot

Je software supply chain is onzichtbaar tot het moment dat hij dat niet meer is. De code die jij niet schreef, draait wel op jouw servers, met jouw tokens, namens jou. Dat is geen reden om geen open-source pakketten te gebruiken, het is een reden om ze te behandelen als wat ze zijn: code waarvan jij het risico draagt, ook al heb je hem niet getypt. Het halve dagje dat je kwijt bent aan inventariseren, pinnen en scripts uitzetten is goedkoper dan één keer al je cloud-sleutels moeten roteren omdat een vergeten postinstall-script ze heeft weggesluisd. Beveiliging is hier geen product dat je aanzet, maar een paar gewoontes die je inbouwt en daarna grotendeels laat automatiseren. Wie zijn afhankelijkheden vastlegt, verifieert en bewaakt, ruilt een sluimerend risico in voor een gecontroleerde, voorspelbare stack. En dat is precies de basis waarop je verder durft te bouwen.