Geeky Saturday Paasspecial: als je security scanner je verraadt: en waarom je data niet meer veilig is in Amerikaanse handen

Het is morgen Pasen. En dat betekent bij ons: een Geeky Saturday met wat extra ruimte. Niet één onderwerp, maar twee. Twee verhalen die op het eerste gezicht los van elkaar staan, maar bij nader inzien aan hetzelfde probleem raken: vertrouwen. Vertrouwen in de tools die je gebruikt. Vertrouwen in de infrastructuur waarop je draait. En de vraag wie er écht de controle heeft over jouw data.

Welkom bij de Geeky Saturday Paasspecial.

Flowerbed engineering is gecertificeerd partner van Arctic Wolf, Microsoft, Fortinet, Trend Micro en KnowBe4. Samen met Databalance, waarmee we zijn samengegaan, helpen we organisaties dagelijks met IT-infrastructuur, security en datasoevereiniteit. Die breedte maakt dat we de onderwerpen van vandaag niet alleen volgen, maar ook in de praktijk uitvoeren.

‍

Deel 1: hoe een gehackte security scanner de AI-tools van miljoenen developers besmette

We beginnen met het nieuws van deze week, want het is te goed om te laten liggen.

Op 24 maart 2026 ontdekte een onderzoeker dat LiteLLM, de meest gebruikte Python-library voor AI-developers om met één interface meerdere AI-modellen aan te sturen, een kwaadaardige payload bevatte. LiteLLM wordt zo'n 97 miljoen keer per maand gedownload. Het pakket zit in vrijwel elk serieus AI-project: van OpenAI-integraties tot Anthropic, Google en alles daartussenin.

Maar de aanval begon niet bij LiteLLM. Hij begon bij Trivy.

De aanval stap voor stap

Trivy is een populaire open source security scanner. Het is precies het soort tool dat je installeert omdat je véilig wil werken. Developers draaien Trivy in hun CI/CD pipeline om code te checken op kwetsbaarheden voordat die live gaat. Het is een verdedigingstool.

Op 19 maart compromitteerden de aanvallers, een groep die onderzoekers TeamPCP noemen, de Trivy-repository van Aqua Security. Ze injecteerden malware in de trivy-action, een automatiseringsscript dat developers in hun bouwproces draaien. Wie Trivy gebruikte, stuurde voortaan onbewust zijn CI/CD-geheimen naar de aanvallers.

LiteLLM gebruikte Trivy in zijn eigen bouwproces. Toen LiteLLM op 24 maart een nieuwe versie bouwde, draaide die besmette Trivy-action mee; en lekte de PyPI-publicatietoken naar TeamPCP. Met die token publiceerden ze zelf twee nieuwe LiteLLM-versies op PyPI: 1.82.7 en 1.82.8. Met hun eigen payload erin.

‍

Wat de payload deed

Zodra iemand de besmette versie installeerde en Python opstartte, werd automatisch een script uitgevoerd. Dat script deed drie dingen. Ten eerste: credentials stelen. SSH-sleutels, .env-bestanden, AWS/GCP/Azure-tokens, Kubernetes-configuraties, database-wachtwoorden, API-keys; alles wat op de machine stond. Ten tweede: laterale beweging in Kubernetes-clusters, waarbij de aanvallers zichzelf toegang gaven tot de volledige cluster-omgeving. Ten derde: een persistente backdoor installeren als systemd-service, zodat de aanvallers ook na een herstart toegang hielden.

De payload bevatte ook een bug: een fork bomb die op sommige systemen de machine liet crashen. Niet de bedoeling van de aanvallers, maar het zorgde er wel voor dat sommige developers direct alarm sloegen.

Waarom dit ook voor jouw organisatie relevant is

Je hoeft geen Python-developer te zijn om geraakt te worden. Als jouw leveranciers, SaaS-platforms of interne tools AI-functionaliteit gebruiken, is de kans reël dat LiteLLM ergens in die keten zit. Een tool die jouw tool gebruikt, die jouw tool gebruikt.

De vraag is niet alleen: „Hebben wij LiteLLM geïnstalleerd?“ De vraag is: „Heeft één van onze leveranciers dat gedaan, en heeft die installatie onze cloud-credentials of onze CI/CD-omgeving bereikt?“

Dat is precies de vraag die moeilijk te beantwoorden is als je geen zicht hebt op wat er in je omgeving draait. Arctic Wolf, een van onze partners, publiceerde deze week direct een security bulletin over de TeamPCP-campagne. Dat is niet toevallig: dit soort supply chain-aanvallen zijn precies wat MDR-platformen detecteren op gedragsniveau. Niet wat er binnenkomt, maar wat er écht gebeurt na installatie.

‍

Deel 2: jouw data in Amerikaanse handen; waarom dat een strategische keuze is geworden

En nu het tweede verhaal. Eentje dat minder in het nieuws staat, maar op de lange termijn misschien wel groter is.

De wereld kijkt anders naar datasoevereiniteit dan twee jaar geleden. Niet als een compliance-checkbox, maar als een strategische keuze. En die verschuiving versnelt.

‍

Wat datasoevereiniteit eigenlijk is

Datasoevereiniteit gaat over de vraag: wie heeft er écht toegang tot jouw data? Niet alleen technisch, maar ook juridisch en geopolitiek.

Organisaties die hun data in de public cloud hebben staan, Microsoft Azure, AWS, Google Cloud, werken met Amerikaanse bedrijven. Die bedrijven vallen onder de US CLOUD Act. Die wet geeft de Amerikaanse overheid het recht om data op te vragen van Amerikaanse bedrijven, ook als die data fysiek in Europa staat. Microsoft kan geen absolute garantie geven dat EU-data nooit bij een Amerikaans overheidsverzoek terechtkomt. Dat staat letterlijk in hun eigen documentatie.

Dat was al zo. Maar twee dingen zijn veranderd.

Ten eerste: de geopolitieke context. De relatie tussen Europa en de VS is minder vanzelfsprekend dan een paar jaar geleden. Handelsspanningen, tarieven, wisselende allianties, organisaties die blind vertrouwen op de stabiliteit van die relatie, nemen een risico dat ze een paar jaar geleden niet zagen.

Ten tweede: de regelgeving. De Cyberbeveiligingswet komt eraan; verwacht in Q2 2026. De ABRO (Algemene Beveiligingseisen voor Rijksoverheidsopdrachten) is al van kracht. NIS2 maakt ketenverantwoordelijkheid verplicht. Organisaties in vitale sectoren moeten aantoonbaar grip hebben op hun data en hun keten. „We draaien op Azure“ is geen antwoord meer op de vraag wie er toegang heeft tot jouw bedrijfskritische informatie.

‍

Het publieke model werkt, maar niet voor alles

Dit betekent niet dat de public cloud slecht is. Integendeel. Voor een groot deel van wat organisaties doen, is de public cloud uitstekend. Snel, schaalbaar, goedkoop, up-to-date. De nieuwste AI-modellen draaien er. De nieuwste security-updates komen er vanzelf. Dat is echte waarde.

Maar er is een categorie data waarvoor dat anders ligt. Bedrijfskritische informatie. Klantgegevens die niet buiten de EU mogen. Strategische documenten. R&D-data. Medische dossiers. Financieel gevoelige informatie. Voor die categorie is „we laten het door OpenAI of Azure samenvatten“ geen verstandige keuze, ook als de provider zegt dat de data niet wordt opgeslagen.

Het probleem is: hoe weet je welke data kritiek is en welke niet? En hoe zorg je dat je die scheiding in de praktijk ook echt maakt?

‍

Hoe doen wij dat dan?

‍
Dit is waar Flowerbed Engineering het verschil maakt.

Wij beschikken over hoogwaardige infrastructuur in Nederlandse datacenters, uitgerust voor het draaien van krachtige AI-modellen. Dat klinkt technisch, maar de uitkomst is juist heel praktisch: wij kunnen lokale AI aanbieden. AI die draait in een gecontroleerde omgeving, op infrastructuur binnen Nederland, met duidelijke afspraken over datagovernance.

‍

Daardoor wordt een hybride aanpak mogelijk die eerder vooral was weggelegd voor grote enterprise-organisaties.

Stap één is het classificeren van jouw data. Via AI-governance, onderdeel van onze Business Services, bepalen we welke informatie publiek mag zijn en welke als kritisch moet worden behandeld. Dat gebeurt niet handmatig, maar grotendeels geautomatiseerd. AI helpt daarbij om de gevoeligheid van informatie te beoordelen. Denk aan documenten, e-mails, bestanden en databases. Wat is openbaar? Wat is intern? Wat is bedrijfskritisch?

Stap twee is de routering. Informatie die niet kritisch is, kan prima worden verwerkt via publieke of enterprise AI-licenties, zoals ChatGPT, Copilot, Claude of Gemini. Daar zitten vaak de meest actuele en krachtige modellen. Maar zodra informatie als kritisch is geclassificeerd, wordt die niet via publieke systemen verwerkt. Dan draait het op lokale modellen, binnen een gecontroleerde omgeving, op infrastructuur in Nederlandse datacenters.

Het resultaat is helder: organisaties profiteren van de nieuwste AI-mogelijkheden voor niet-kritische werkzaamheden, terwijl hun meest gevoelige data binnen de juiste grenzen blijft. Minder afhankelijkheid van buitenlandse wet- en regelgeving, meer grip op waar data wordt verwerkt, en meer zekerheid over wat er met prompts en bedrijfsinformatie gebeurt.

De kern is simpel: soevereiniteit is geen losse producteigenschap, maar een architectuurkeuze. En juist die keuze helpen wij organisaties concreet maken, met een aanpak die veilig, praktisch en toekomstbestendig is.

‍

Wat dit voor jou betekent

Als je organisatie AI wil inzetten, en dat gaat vrijwel iedereen doen, dan is de vraag niet alleen „welk model“ maar ook „waar draait dit en wie heeft er toegang toe?“

De organisaties die die vraag nu stellen, staan straks beter dan de organisaties die later moeten uitleggen waarom hun bedrijfskritische informatie door een Amerikaans systeem is gegaan. Niet omdat dat persé fout is, maar omdat je het bewust moet kiezen. En kunnen verantwoorden.

Vision on Data Governance, een van onze Business Services waarbij Flowerbed engineering organisaties begeleidt, is precies het startpunt voor deze analyse. Samen met de lokale AI-infrastructuur van Databalance vormt dat een hybride aanpak die voor het eerst echt toegankelijk is voor middelgrote en grote organisaties.

Als gecertificeerd partner hebben we de kennis, de infrastructuur en de expertise om dit voor jouw organisatie concreet te maken. Neem gerust contact op; we praten er graag over.

Fijne Pasen.