---
title: "Supply chain attacks: hoe gekaapte dependencies jouw software bedreigen | Coding Agency"
description: "In 2026 werden Axios, Checkmarx en SAP npm-pakketten gecompromitteerd door statelijke hackers. Deze aanvallen raken niet alleen Big Tech — elke applicatie die op open-source dependencies draait is een potentieel doelwit. Zo bescherm je jouw software."
url: https://coding.agency/kennisbank/supply-chain-attacks-software-dependencies
source: Coding Agency (https://coding.agency)
language: nl
---

Architectuur  8 min leestijd  

#  Supply chain attacks: hoe gekaapte dependencies jouw software bedreigen. 

In 2026 werden Axios, Checkmarx en SAP npm-pakketten gecompromitteerd door statelijke hackers. Deze aanvallen raken niet alleen Big Tech — elke applicatie die op open-source dependencies draait is een potentieel doelwit. Zo bescherm je jouw software.

 [ Jasper Koers ](https://coding.agency/over/jasper-koers) · 11 mei 2026 

 ##  In het kort 

- In 2026 zijn meerdere veelgebruikte open-source pakketten gecompromitteerd, waaronder Axios (70M+ wekelijkse downloads), Checkmarx-tools en SAP npm-pakketten
- De Axios-aanval was het werk van een Noord-Koreaanse staatsactor — supply chain attacks zijn geen hypothetisch risico meer
- Eén gecompromitteerd pakket kan via transitieve dependencies duizenden applicaties raken binnen enkele uren
- Lockfiles, dependency-audits en geautomatiseerde CVE-monitoring zijn geen luxe maar basismaatregelen
- De NIS2-richtlijn verplicht organisaties in essentiële sectoren om supply chain risico's actief te beheersen

## 2026: het jaar van de supply chain attacks

Eind maart 2026 ontdekten beveiligingsonderzoekers dat [Axios — het populairste HTTP-pakket voor JavaScript met meer dan 70 miljoen wekelijkse downloads](https://github.com/axios/axios/issues/10636) — was gecompromitteerd. Een aanvaller had via een overgenomen maintainer-account twee kwaadaardige versies gepubliceerd (1.14.1 en 0.30.4) die een Remote Access Trojan installeerden op de machines van ontwikkelaars. De malware werkte op macOS, Windows én Linux.

De kwaadaardige versies waren slechts drie uur live voordat ze werden verwijderd. Maar drie uur is bij een pakket met die downloadaantallen genoeg om duizenden ontwikkelomgevingen te infecteren. [Google Cloud's Threat Intelligence-team wees de aanval toe aan Sapphire Sleet](https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package), een Noord-Koreaanse staatsactor die sinds 2020 actief is.

En Axios was niet de enige. In dezelfde periode werden [Checkmarx' beveiligingstools en VS Code-extensies gecompromitteerd](https://checkmarx.com/blog/supply-chain-security-incident-update/), raakten [SAP npm-pakketten besmet met versleutelde credential-diefstal](https://thehackernews.com/2026/04/sap-npm-packages-compromised-by-mini.html), en werd [de Bitwarden CLI — een wachtwoordmanager voor developers — gekaapt via dezelfde campagne](https://thehackernews.com/2026/04/malicious-kics-docker-images-and-vs.html).

## Wat is een supply chain attack precies?

Bij een traditionele aanval probeert iemand direct in te breken in jouw applicatie — via een SQL-injectie, een gestolen wachtwoord of een openstaande poort. Bij een supply chain attack is het doelwit niet jouw code, maar een component waar jouw code van afhankelijk is. Vergelijk het met een supermarkt die gecontamineerde ingrediënten van een leverancier ontvangt: het probleem zit niet in de keuken van het restaurant, maar in de toeleveringsketen.

Moderne software bestaat niet uit één codebase. Een gemiddelde webapplicatie heeft honderden dependencies — pakketten die je via npm (JavaScript), Composer (PHP), PyPI (Python) of Maven (Java) binnenhaalt. Elk pakket heeft op zijn beurt weer eigen dependencies. Die keten — van jouw code naar pakket A, dat pakket B nodig heeft, dat pakket C importeert — is de supply chain.

Een aanvaller die één schakel in die keten compromitteert, bereikt in één klap alle projecten die direct of indirect van dat pakket afhangen. Dat maakt supply chain attacks zo effectief: je hoeft niet duizend bedrijven aan te vallen, je hoeft alleen het pakket aan te vallen dat die duizend bedrijven gebruiken.

## Wat er in 2026 concreet misging

### Axios: drie uur, miljoenen potentiële slachtoffers

De aanval op Axios was chirurgisch. De aanvaller voegde een ogenschijnlijk onschuldige dependency toe (`plain-crypto-js`) zonder de broncode van Axios zelf te wijzigen. Via een `postinstall`-hook — een script dat automatisch draait na installatie — werd een cross-platform RAT (Remote Access Trojan) gedownload en uitgevoerd. [Microsoft publiceerde een gedetailleerde mitigatie-handleiding](https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/) en [CISA gaf een officieel beveiligingsadvies](https://www.cisa.gov/news-events/alerts/2026/04/20/supply-chain-compromise-impacts-axios-node-package-manager) uit.

### Checkmarx, Trivy en Bitwarden: de beveiligingstools zelf als doelwit

Bijzonder verontrustend was de campagne tegen Checkmarx. Hier compromitteerde de groep TeamPCP eerst [Aqua Security's vulnerability scanner Trivy via GitHub Actions](https://www.sophos.com/en-us/blog/supply-chain-attacks-hit-checkmarx-and-bitwarden-developer-tools). Met de gestolen CI/CD-secrets konden ze vervolgens Checkmarx' eigen beveiligingstools infecteren — inclusief Docker-images met meer dan vijf miljoen cumulative pulls en twee VS Code-extensies. De gecompromitteerde extensies downloadden bij activatie een kwaadaardig script als `mcpAddon.js`.

De ironie is pijnlijk: de tools die developers inzetten om kwetsbaarheden te vinden, werden zelf het voertuig voor de aanval.

### SAP npm-pakketten: versleutelde credential-diefstal

Op 29 april 2026 werden meerdere SAP-gerelateerde npm-pakketten besmet met AES-256-GCM versleutelde payloads die credentials stalen van ontwikkelomgevingen. De versleuteling maakte het voor geautomatiseerde scanners lastiger om de malware te detecteren.

## Waarom dit ook jouw applicatie raakt

De reactie die wij vaak horen bij opdrachtgevers is: "wij zijn geen Big Tech, wij zijn geen doelwit." Dat klopt — je bent niet het primaire doelwit. Maar bij een supply chain attack hoef je dat niet te zijn. Je bent doelwit omdat je toevallig hetzelfde pakket gebruikt als miljoenen anderen.

Concreet: als jouw webapplicatie Axios gebruikt voor HTTP-requests (en dat doen de meeste JavaScript-applicaties), dan was jouw ontwikkelomgeving op 30 maart 2026 potentieel geïnfecteerd als je op dat moment `npm install` of `npm update` draaide zonder een lockfile die de versie vastzette. Niet omdat iemand het op jou gemunt had, maar omdat je in de blast radius van de aanval zat.

Hetzelfde geldt voor PHP-projecten die Composer gebruiken, Python-projecten met pip, of Java-projecten met Maven. Het ecosysteem verschilt, het patroon is identiek.

## Hoe wij supply chain risico's beheersen

Bij Coding Agency is dependency management geen bijzaak maar een structureel onderdeel van ons ontwikkelproces. Dit zijn de concrete maatregelen die we bij elk project inrichten:

### 1. Lockfiles als eerste verdedigingslinie

Elk project gebruikt een lockfile (`composer.lock` voor PHP, `package-lock.json` voor JavaScript) die exact vastlegt welke versie van welk pakket geïnstalleerd wordt. Zonder lockfile bepaalt de package manager bij elke installatie opnieuw welke versie er binnenkomt — en kan een zojuist gepubliceerde kwaadaardige versie automatisch worden opgehaald. Met een lockfile wordt alleen de versie geïnstalleerd die eerder is getest en goedgekeurd.

### 2. Geautomatiseerde dependency-audits

In onze [CI/CD-pipelines](https://coding.agency/kennisbank/continuous-deployment-ci-cd) draaien geautomatiseerde checks die dependencies scannen op bekende kwetsbaarheden (CVE's). Tools als `npm audit`, `composer audit` en Dependabot controleren bij elke commit of er pakketten met bekende problemen in de dependency tree zitten.

### 3. Versie-pinning en controlled updates

We gebruiken strikte versie-ranges in plaats van brede wildcards. Een dependency als `"axios": "^1.14.0"` accepteert automatisch nieuwe minor-versies, inclusief een gecompromitteerde 1.14.1. Door bewust te pinnen op exacte versies en updates handmatig te reviewen, behouden we controle over wat er in de codebase terechtkomt.

### 4. Postinstall-scripts evalueren

De Axios-aanval werkte via een `postinstall`-hook — een script dat automatisch na installatie draait. We evalueren postinstall-scripts van dependencies en gebruiken waar mogelijk `--ignore-scripts` voor niet-vertrouwde pakketten.

### 5. Minimale dependency-footprint

Hoe minder dependencies, hoe kleiner het aanvalsoppervlak. Bij elk nieuw pakket dat we overwegen, stellen we de vraag: is dit pakket de extra afhankelijkheid waard, of kunnen we de functionaliteit zelf implementeren? Een [security-by-design aanpak](https://coding.agency/kennisbank/security-by-design-laravel) begint bij bewuste keuzes over wat je wel en niet binnenhaalt.

## NIS2 en supply chain security

De [NIS2-richtlijn](https://coding.agency/kennisbank/nis2-en-softwareontwikkeling), die in Nederland is omgezet in de Cyberbeveiligingswet, verplicht organisaties in essentiële en belangrijke sectoren om supply chain risico's actief te beheersen. Artikel 21 lid 2(d) noemt expliciet de beveiliging van de toeleveringsketen, inclusief de relatie met directe leveranciers en dienstverleners.

Voor softwareleveranciers zoals wij betekent dat concreet dat opdrachtgevers steeds vaker vragen stellen over hoe wij omgaan met dependency management, vulnerability monitoring en incident response bij gecompromitteerde pakketten. In onze [NIS2 supplier alignment](https://coding.agency/kennisbank/nis2-supplier-alignment-coding-agency) beschrijven we hoe onze werkwijze aansluit op deze eisen.

Voor opdrachtgevers in NIS2-sectoren (energie, transport, gezondheidszorg, financiële diensten, digitale infrastructuur) is het niet langer optioneel om te weten hoe hun softwareleverancier met supply chain risico's omgaat. Het is een wettelijke verplichting.

## Wat kun je zelf doen?

Vier vragen die je deze week aan je ontwikkelteam of softwareleverancier kunt stellen:

1. **Gebruiken jullie lockfiles en worden die meegecommit in versiebeheer?** Als het antwoord "nee" of "weet ik niet" is, draait je applicatie mogelijk op dependencies die niemand bewust heeft goedgekeurd.
2. **Draaien er geautomatiseerde dependency-audits in de CI/CD-pipeline?** Handmatig controleren schaalt niet. Geautomatiseerde scanning op CVE's is de minimale standaard.
3. **Hoe snel kunnen jullie reageren als een dependency gecompromitteerd wordt?** Bij de Axios-aanval was het verschil tussen drie uur en drie dagen het verschil tussen "potentieel geraakt" en "actief geïnfecteerd." Een incident response-plan voor supply chain events is geen overbodige luxe.
4. **Hoeveel directe en transitieve dependencies heeft onze applicatie?** Als niemand dat getal kent, kent ook niemand het aanvalsoppervlak. `npm ls --all | wc -l` of `composer show -t` geeft een eerste indicatie.

## De trend: het wordt erger voordat het beter wordt

[Het Software Supply Chain Security Report 2026 van ReversingLabs](https://www.reversinglabs.com/sscs-report) en [onderzoek van Zscaler ThreatLabz](https://www.zscaler.com/blogs/security-research/supply-chain-attacks-surge-march-2026) laten een stijgende trend zien: supply chain attacks zijn in volume en complexiteit toegenomen. De combinatie van statelijke actoren (Noord-Korea, China), georganiseerde cybercriminaliteit en een groeiend ecosysteem van open-source dependencies maakt dit een structureel probleem dat niet vanzelf verdwijnt.

De tools waarmee we software bouwen — package managers, CI/CD-pipelines, IDE-extensies — zijn zelf onderdeel geworden van het aanvalsoppervlak. Dat betekent niet dat we moeten stoppen met het gebruik van open-source software. Het betekent wel dat we dezelfde zorgvuldigheid moeten toepassen op onze supply chain als op onze eigen code.

## Onze aanpak

Bij Coding Agency is supply chain security ingebouwd in ons standaard ontwikkelproces. Elke applicatie die we bouwen heeft lockfiles, geautomatiseerde audits en een dependency update-beleid. Bij bestaande projecten die we overnemen, is een supply chain audit onderdeel van onze [second opinion](https://coding.agency/kennisbank/second-opinion-software).

Twijfel je of jouw applicatie voldoende beschermd is tegen supply chain risico's? [Neem contact op](https://coding.agency/contact) — we lopen je dependency tree door en geven je een eerlijk beeld van waar je staat.

##  Veelgestelde vragen 

 Een supply chain attack is een aanval waarbij niet jouw eigen code het doelwit is, maar een pakket of tool waar jouw software van afhankelijk is. Denk aan een npm-pakket, een Composer-library of een VS Code-extensie. De aanvaller compromitteert het pakket bij de bron — via een gehackt maintainer-account, een kwaadaardige pull request of een geïnfecteerde CI/CD-pipeline — waarna iedereen die het pakket installeert of updatet de malware binnenkrijgt. 

 Populaire pakketten als Axios hebben meer dan 70 miljoen wekelijkse downloads. Zodra een aanvaller een kwaadaardige versie publiceert, wordt die automatisch opgehaald door alle projecten die dat pakket als dependency hebben en een brede versie-range gebruiken (bijv. ^1.14.0). Binnen een paar uur kan de malware op duizenden servers en ontwikkelmachines draaien voordat iemand het opmerkt. 

 Nee. Supply chain attacks treffen elk ecosysteem met package managers: npm (JavaScript), Composer (PHP), PyPI (Python), Maven (Java), RubyGems (Ruby) en meer. De Checkmarx-aanval van 2026 trof ook VS Code-extensies en Docker-images. Het patroon is universeel: overal waar je code van derden binnenhaalt, bestaat het risico. 

 Wij gebruiken lockfiles (composer.lock, package-lock.json) die exact vastleggen welke versie geïnstalleerd wordt. Daarnaast draaien we geautomatiseerde dependency-audits, monitoren we CVE-meldingen en gebruiken we tools als Dependabot en Snyk voor vroegtijdige detectie. Bij nieuwe projecten richten we dit standaard in als onderdeel van de CI/CD-pipeline. 

 Gerelateerde expertise — Maatwerk software **Maatwerk software laten maken?** Bekijk onze aanpak, werkwijze en referentieprojecten. Vanaf € 3.000, 16+ jaar ervaring, 150+ projecten opgeleverd.

 [ Bekijk onze aanpak ](https://coding.agency/expertises/maatwerk-software-laten-maken) [ Gratis prijsindicatie ](https://coding.agency/prijsindicatie) 

 Onderwerpen [Supply Chain](https://coding.agency/kennisbank?q=Supply+Chain) [Security](https://coding.agency/kennisbank?q=Security) [Dependencies](https://coding.agency/kennisbank?q=Dependencies) [npm](https://coding.agency/kennisbank?q=npm) [Composer](https://coding.agency/kennisbank?q=Composer) [Open Source](https://coding.agency/kennisbank?q=Open+Source) [NIS2](https://coding.agency/kennisbank?q=NIS2) [DevSecOps](https://coding.agency/kennisbank?q=DevSecOps) 

  ##  Gerelateerde artikelen 

 [ 

 Architectuur### Security by design in Laravel

Waarom beveiliging geen feature is maar een ontwerpprincipe dat je vanaf commit één doorvoert.

 Lees artikel 

 ](https://coding.agency/kennisbank/security-by-design-laravel) [ 

 Architectuur### Continuous deployment (CI/CD)

Automatisch en veilig deployen met pipelines, tests en rollbacks.

 Lees artikel 

 ](https://coding.agency/kennisbank/continuous-deployment-ci-cd) [ 

 Juridisch### NIS2 en softwareontwikkeling

Wat de Europese NIS2-richtlijn betekent voor jouw software en ontwikkelproces.

 Lees artikel 

 ](https://coding.agency/kennisbank/nis2-en-softwareontwikkeling) 

##  Hulp nodig? 

Vragen over dit onderwerp? Laten we het erover hebben.

 [ Neem contact op ](https://coding.agency/contact)

---
*Bron: [Coding Agency](https://coding.agency/kennisbank/supply-chain-attacks-software-dependencies)*