InzichtenCybersecurity
De campagnes "Mini Shai-Hulud" en "Megalodon": waarom uw software supply chain nu de voordeur is
Mini Shai-Hulud en Megalodon laten zien hoe aanvallers CI/CD, package-registries en vertrouwen in builds raken, niet uw productieservers. Wat dat betekent voor bedrijfsrisico en wat u nu kunt doen.
Een paar jaar geleden maakten de meeste bedrijven zich vooral zorgen over aanvallers die productiesystemen binnendrongen. Vandaag is het ongemakkelijkere scenario dat aanvallers uw applicatie helemaal niet hoeven binnen te breken. Ze kunnen de systemen raken die software bouwen, testen, inpakken en publiceren.
Dat is de belangrijke les uit de campagnes Mini Shai-Hulud en Megalodon. Dit waren geen simpele gevallen waarin iemand een verdacht pakket uploadde en hoopte dat niemand het opmerkte. Ze richtten zich op het vertrouwensmechanisme achter moderne softwareontwikkeling: package repositories, CI/CD-pipelines, ontwikkelomgevingen, gecachte build-artefacten, cloudcredentials, OIDC-tokens en build provenance.
In gewone taal: de systemen waar teams op vertrouwen om snel software te leveren, werden het aanvalsoppervlak. Handig voor ontwikkelaars. Helaas ook erg handig voor aanvallers.
Wat gebeurde er?
Midden 2026 compromitteerde de dreigingsgroep Team PCP in grote mate de npm- en pip-ecosystemen, met honderden getroffen projecten en pakketten met meer dan 500 miljoen downloads.
De campagnes werkten omdat moderne softwareontwikkeling diep met elkaar verbonden is. Ontwikkelaars installeren open-sourcepakketten. CI/CD-pipelines bouwen applicaties automatisch. Package registries distribueren updates. Cloudplatforms vertrouwen op kortlevende identity tokens. Buildsystemen genereren provenance-metadata om aan te tonen waar software vandaan komt.
Al dat vertrouwen is nuttig. Het is ook precies wat de aanvallers misbruikten.
Bij Mini Shai-Hulud vergiftigden aanvallers CI/CD-caches en haalden ze OIDC-tokens uit. Daardoor konden ze kwaadaardige pakketten publiceren die leken te komen uit legitieme buildprocessen. Sommige pakketten hadden zelfs geldige build provenance. Dat is het vervelende deel. Het keurmerk zag er echt uit, maar het pakket was niet veilig.
Bij Megalodon verschoof de focus naar massale repository-compromittering en injectie van kwaadaardige workflows. Aanvallers richtten zich op GitHub-repositories en CI/CD-workflows om secrets, cloudcredentials, SSH-keys, publishing tokens en andere gevoelige informatie te verzamelen.
Dit was geen malware die stilletjes in een vergeten dependency zat. Dit was malware die de softwarefabriek zelf aanviel.
Waarom geldige provenance niet genoeg was
Build provenance moet een belangrijke vraag beantwoorden: is deze software gebouwd door het proces dat wij vertrouwen?
Dat is waardevol, maar het beantwoordt niet automatisch een tweede, even belangrijke vraag: was het vertrouwde proces al gecompromitteerd?
Dat onderscheid telt. Als aanvallers een build-cache vergiftigen, een workflow manipuleren of het token stelen dat door een vertrouwde pipeline wordt gebruikt, kan het resulterende pakket er nog steeds legitiem uitzien. Het papierwerk klopt, terwijl de inhoud stilletjes iets vijandigs doet.
Denk aan een verzegelde doos van een vertrouwde leverancier. Het label klopt, de route klopt en de leveranciersnaam klopt. Helaas kan de doos nog steeds iets bevatten dat u echt niet besteld had.
Geen jargonbelasting. Wel een heel dure aanname.
De aanvalsketen in het kort
| Doel | Wat aanvallers misbruikten | Waarom het ertoe doet |
|---|---|---|
| npm- en pip-pakketten | Kwaadaardige pakketversies | Ontwikkelaars en CI-systemen kunnen ze automatisch installeren |
| CI/CD-caches | Vergiftigde build-artefacten | Vertrouwde jobs kunnen door aanvallers gecontroleerde inhoud hergebruiken |
| OIDC-tokens | Kortlevende identity tokens | Aanvallers kunnen publiceren als vertrouwde pipelines |
| GitHub-workflows | Kwaadaardige workflowwijzigingen | Secrets kunnen tijdens builds worden verzameld |
| Ontwikkelomgevingen | Lokale tokens en credentials | Eén machine kan veel systemen blootleggen |
| Build provenance | Geldige metadata op vergiftigde pakketten | Security tooling kan het verkeerde ding vertrouwen |
De ongemakkelijke realiteit is dat veel organisaties deze systemen eerst voor snelheid en pas daarna voor security ontwierpen. Aanvallers merkten dat op en richten zich nu op de kloof tussen gemak en controle.
Waarom bedrijfseigenaren dit moeten volgen
Dit is niet alleen een probleem voor ontwikkelaars.
Als uw bedrijf software bouwt, cloudinfrastructuur gebruikt, op SaaS-platformen leunt of met externe developmentteams werkt, maakt uw software supply chain deel uit van uw bedrijfsrisico. Een gecompromitteerd pakket of een gecompromitteerde CI/CD-pipeline kan veel meer blootleggen dan broncode. Aanvallers kunnen toegang krijgen tot de systemen die uw bedrijfskritische applicaties uitrollen, configureren en draaien.
| Asset | Bedrijfsimpact |
|---|---|
| GitHub-tokens | Toegang tot broncode of manipulatie van repositories |
| Cloudcredentials | Compromittering van infrastructuur of datalek |
| CI/CD-secrets | Overname van de deployment pipeline |
| SSH-keys | Toegang tot servers |
| API-keys | Misbruik van diensten van derden |
| Publishing tokens | Kwaadaardige software uitgebracht onder uw naam |
Het grootste risico is niet alleen diefstal. Het is vertrouwen.
Als aanvallers kwaadaardige pakketten via uw pipeline publiceren, kunnen klanten de software zien als afkomstig van u. Technisch gezien klopt dat ook. Dan wordt een technisch incident een vertrouwenskwestie met klanten, een juridische kwestie, een merkkwestie en een hoofdpijndossier voor de directie. Een charmant combiplankje dat niemand besteld had.
Waarom dit het securitygesprek verandert
Veel teams volgen al de gebruikelijke security-checklist. Ze zetten MFA aan, scannen dependencies, genereren SBOMs, signen builds, gebruiken trusted publishing, schakelen provenance in en automatiseren deployments. Dat zijn goede praktijken, en die moeten blijven.
Het probleem is dat Mini Shai-Hulud en Megalodon laten zien dat aanvallers dieper het ontwikkelproces in gaan. Ze stelen niet meer alleen wachtwoorden of misbruiken productieservers. Ze vallen workflowontwerp, token scope, cachegedrag, ontwikkelaarstooling en automatiseringsvertrouwen aan.
Dat betekent dat CI/CD niet langer als achtergrondplumbing kan worden gezien. Het verdient dezelfde aandacht als productie, omdat aanvallers het al zien als een route naar productie.
Wat teams nu moeten doen
Dit is geen moment voor paniek. Paniek is luidruchtig, duur en doorgaans verschrikkelijk in YAML. Het is wel een goed moment om de basis aan te scherpen en te bekijken of uw softwareleveringsproces echt zo betrouwbaar is als iedereen aanneemt.
| Prioriteit | Actie | Waarom het ertoe doet |
|---|---|---|
| Dependencies auditen | Controleren of getroffen pakketten of versies zijn gebruikt | Kwaadaardige code kan tijdens installatie of build zijn uitgevoerd |
| Secrets roteren | GitHub-, npm-, pip-, cloud-, SSH- en CI/CD-credentials vervangen | Uitlekte secrets moet u als verbrand beschouwen |
| Workflows reviewen | GitHub Actions en pipelinewijzigingen inspecteren | Workflowbestanden kunnen aanvalsinstrumenten worden |
| OIDC afschermen | Trusted publishing beperken per branch, workflow, job en environment | Brede trust creëert een brede blast radius |
| Runners hardenen | Ephemeral runners gebruiken en buildomgevingen isoleren | CI-runners raken vaak gevoelige secrets aan |
| Caches reviewen | Build-caches legen en valideren | Vergiftigde caches kunnen schone builds overleven |
| Provenance zorgvuldig monitoren | Provenance zien als één signaal, niet als bewijs van veiligheid | Geldige metadata kan nog steeds vergiftigde output verpakken |
| Ontwikkelaarsmachines volgen | Lokale tools, tokens, configbestanden en persistence hooks controleren | Ontwikkelaars maken nu deel uit van de security perimeter |
Beveilig de pipeline alsof die uw bedrijf levert, want dat doet hij.
De grotere les
Open-sourcepakketten zijn krachtig. CI/CD-automatisering is onmisbaar. OIDC is nuttig. Build provenance telt mee. Package registries houden moderne ontwikkeling draaiende. Geen van dit is slecht. De meeste moderne softwareteams kunnen zonder deze middelen niet efficiënt werken.
Maar ze zijn geen magische schilden. Ze vragen om duidelijke trust boundaries, least-privilege-toegang, actieve monitoring, degelijke review en betrouwbare governance. Niet omdat governance spannend klinkt. Dat doet het niet. Maar omdat saaie controls vaak voorkomen dat incidenten wél spannend worden.
En in cybersecurity is “spannend” meestal code voor “iemand heeft een slechte week.”
Slotgedachte
De volgende grote breach hoeft niet te beginnen met een phishingmail of een blootgestelde productieserver. Het kan beginnen met een package-update, een CI/CD-cache, een GitHub-workflow of een OIDC-token dat door een pipeline wordt uitgegeven die iedereen vertrouwde omdat “zo werkt de build nu eenmaal.”
Daarom is kennis van campagnes als Mini Shai-Hulud en Megalodon belangrijk. Het zijn niet alleen incidenten. Het zijn waarschuwingen over waar aanvallers heen gaan.
Uw software supply chain is geen achtergrondplumbing meer. Het is deel van uw security perimeter. En zoals bij alle belangrijke plumbing merkt u meestal pas hoe belangrijk het is als het stukgaat.