Supply chain-aanvallen op open-source software: de nieuwe norm in 2025

Aanvallers richten zich steeds vaker op open-source bibliotheken om duizenden bedrijven tegelijk te raken. Wat zijn supply chain-aanvallen en hoe bescherm je je ertegen?

Supply chain aanval open source software 2025

In maart 2025 werden meer dan 4.200 npm-pakketten geïdentificeerd die kwaadaardige code bevatten. In februari werd een populaire Python-bibliotheek met 8 miljoen downloads per week gecompromitteerd. Supply chain-aanvallen zijn geen nieuw fenomeen, maar ze worden steeds geavanceerder en impactvoller.

Wat is een supply chain-aanval?

Een software supply chain-aanval richt zich niet direct op jouw organisatie, maar op de software die jij gebruikt. De redenering van de aanvaller: “Als ik een bibliotheek compromitteer die door duizenden bedrijven wordt gebruikt, bereik ik in één klap duizenden doelwitten.”

Het bekendste voorbeeld is de SolarWinds-aanval van 2020, waarbij aanvallers kwaadaardige code injecteerden in een software-update die door 18.000+ organisaties — waaronder de Amerikaanse overheid — werd geïnstalleerd.

Hoe werken supply chain-aanvallen?

Er zijn meerdere aanvalsvectoren:

1. Typosquatting

Aanvallers publiceren pakketten met namen die lijken op populaire bibliotheken:

Legitiem:    requests (Python)
Nep:         request, requestss, requests-v2

Ontwikkelaars die snel typen of kopiëren installeren onbewust de kwaadaardige versie.

2. Account-takeover

Een aanvaller compromitteert het account van een populaire open-source onderhouder, en pusht een kwaadaardige versie van een legitieme bibliotheek. De gebruikers vertrouwen de bibliotheek al en updaten automatisch.

3. Dependency confusion

Organisaties gebruiken interne pakketten met private namen. Aanvallers publiceren pakketten met dezelfde naam op de publieke registry (npm, PyPI). Package managers geven soms de voorkeur aan de publieke versie — inclusief de malware.

4. Build pipeline-compromis

De CI/CD-pipeline van een project wordt gehackt, zodat kwaadaardige code wordt toegevoegd tijdens het buildproces zonder de broncode aan te raken.

Recente Nederlandse impact

Kwartaal 1 2025 — geïmpacteerde sectoren in NL:

  • Fintech-bedrijven die npm-pakketten gebruiken voor front-end development
  • SaaS-aanbieders met Python-backends
  • DevOps-teams die compromised Docker-images gebruikten

Opvallend: kleine en middelgrote softwarebedrijven worden relatief harder getroffen omdat ze minder capaciteit hebben voor handmatige code-audits.

Hoe bescherm je je organisatie?

Software Composition Analysis (SCA)

SCA-tools scannen je codebase op bekende kwetsbare of kwaadaardige afhankelijkheden. Gratis opties:

# npm audit (ingebouwd)
npm audit

# pip-audit voor Python
pip install pip-audit
pip-audit

# OWASP Dependency Check (breed inzetbaar)
dependency-check --project "MijnProject" --scan ./src

Lock files en pinning

Gebruik altijd lock files (package-lock.json, poetry.lock, requirements.txt met exacte versies). Dit voorkomt dat automatische updates een gecompromitteerde nieuwe versie installeren.

# Slecht (kan elke minor update installeren)
"dependencies": { "axios": "^1.0.0" }

# Goed (exacte versie)  
"dependencies": { "axios": "1.6.8" }

Controleer afhankelijkheden vóór installatie

# Bekijk metadata van een npm-pakket
npm info <pakket-naam>

# Controleer: aanmaken-datum, wekelijkse downloads, maintainers
# Wees extra voorzichtig bij: recent aangemaakt, weinig downloads, onbekende maintainers

Private pakket-registry

Voor kritieke interne pakketten: gebruik een private npm-registry (Nexus, Artifactory, Azure Artifacts). Configureer je package manager zodat interne namen altijd vanuit de private registry komen.

Integriteitschecks

# Verifieer pakketintegriteit met checksums
npm ci  # Gebruikt package-lock.json exact — veiliger dan npm install

# Voor Python: verifieer hashes
pip install --require-hashes -r requirements.txt

De rol van SBOM

Een Software Bill of Materials (SBOM) is een lijst van alle softwarecomponenten in je product — vergelijkbaar met een ingrediëntenlijst op voedsel. De EU Cyber Resilience Act (CRA) verplicht SBOM’s binnenkort voor veel softwareproducten.

Genereer een SBOM voor je project:

# Met syft (open source)
syft packages dir:./src -o spdx-json > sbom.spdx.json

Wanneer ben je (extra) kwetsbaar?

  • Je gebruikt veel externe afhankelijkheden zonder ze te controleren
  • Je loopt automatische dependency updates (Dependabot zonder review)
  • Je hebt geen SCA-tooling in je CI/CD-pipeline
  • Ontwikkelaars installeren willekeurig pakketten zonder goedkeuring
  • Je gebruikt public registries voor interne pakketten

Conclusie

Supply chain-aanvallen zijn de meest sluipende vorm van cyberaanval: je doet niets verkeerd zelf, maar de software die je vertrouwt is gecompromitteerd. De defensie vereist geen enorme investering: voeg npm audit of pip-audit toe aan je CI-pipeline, gebruik lock files, en train je developers om afhankelijkheden kritisch te bekijken.

Bron: GitHub Security Advisory Database, NCSC-NL, CISA Supply Chain Risk Management