Supply chain security: waarom je npm-dependencies gevaarlijker zijn dan je denkt

In mei 2021 infecteerde de SolarWinds-aanval 18.000 organisaties via een software-update. In 2022 werden miljoenen npm-packages besmet via de node-ipc-bibliotheek. In 2024 zat er een backdoor in xz-utils die op het punt stond in alle grote Linux-distributies terecht te komen.

Supply chain-aanvallen zijn effectief omdat ze de beveiligingsperimeter omzeilen via software die je zelf installeert en vertrouwt. En het probleem wordt groter: de gemiddelde Node.js-applicatie heeft 1.000+ transitive dependencies. Weet jij welke ervan kwetsbaar zijn op dit moment?

Het schaalprobleem

In een recent gemonitorde productieomgeving (Belgische KMO, ~10 servers met Node.js en Go-services) telde de monsys-agent:

• 10.854 dependencies over vier ecosystemen (npm, Go, Packagist, PyPI)
• 1.998 CVE-matches na scan tegen OSV.dev
• 14 CRITICAL die niemand kende

Dat zijn geen hypothetische getallen — dat is wat er gevonden werd binnen 90 seconden na activatie van de agent.

Het probleem is niet dat developers slecht zijn in security. Het is dat niemand manueel 10.000+ dependencies kan bijhouden. Je hebt automatisering nodig die continu scant, niet een jaarlijkse pentest die een snapshot geeft.

Drie lagen van supply chain risico

monsys dekt drie verschillende lagen:

Laag 1: OS-packages

De agent leest dpkg -l, rpm -qa, winget list op elke host. De hub matcht dagelijks tegen NVD (National Vulnerability Database) + EPSS (Exploit Prediction Scoring System). EPSS is cruciaal: een CVE met CVSS 9.8 maar EPSS 0.001 (1 op 1000 kans op exploitatie) is minder urgent dan een CVE met CVSS 7.5 en EPSS 0.34.

Internet-exposed processen (nginx, Apache, Node.js op poort 443) krijgen een 1.5× risicofactor bovenop hun CVE-score.

De aanbevelingen tonen wat je nu moet doen — geprioriteerd op CVSS × exposure × EPSS, niet alleen op de CVSS-score.

Laag 2: Container-images

De agent rapporteert docker ps output — gewoon de image-namen, geen rootaccess nodig. De hub draait Trivy server-side tegen elke unieke image. Geen Trivy installeren op de klant-machine, geen extra software, geen aanvullende rechten.

Laag 3: Application dependencies

Dit is de laag die de meeste teams missen: de transitive dependencies van je applicatiecode.

De agent scant lockfiles op de host: package-lock.json / yarn.lock (npm), requirements.txt / Pipfile.lock (pip), composer.lock (PHP/Packagist), Gemfile.lock (Ruby), go.sum (Go). Uit elk lockfile worden (package, versie) tuples geëxtraheerd. De hub batch-queryt OSV.dev per ecosysteem.

Belangrijk: de agent stuurt géén lockfile-inhoud naar de hub. Alleen de geparste (package, versie) tuples — dezelfde informatie die npm ls aan iedereen met shell-toegang geeft. De broncode van je applicatie verlaat de host niet.

De inventaris-pagina aggregeert per host: OS-packages, app-dependencies, services, gebruikers, SSH-keys, open poorten. Direct doorklikbaar naar CVE-status.

Hoe de tijdlijn eruitziet in de praktijk

Het meest overtuigende argument voor continue scanning is de tijdlijn:

• T+0s — Agent geïnstalleerd op tien productieservers
• T+45s — Eerste OSV.dev batch-query terug: 1.998 matches
• T+5min — 10.854 dependencies gemapt over vier ecosystemen, gelinkt aan project-pad + risk score
• T+13min — Operator heeft alle 14 CRITICAL bekeken, fix-versies staan naast elke CVE
• T+17min — Eerste go get -u + redeploy gestart voor drie van de veertien

Vergelijk dat met de traditionele aanpak: een pentest die drie weken duurt, een rapport van tachtig pagina's dat drie weken later arriveert, en dan een prioriteringsdiscussie die nog eens twee weken duurt. De kwetsbaarheid bestaat ondertussen al twee maanden.

Blast-radius correlatie: niet elke CVE is even urgent

Een Critical CVE op een interne testserver is minder urgent dan een Medium CVE op je load balancer. De blast-radius CVE-prioritering houdt daar automatisch rekening mee.

De hub doet een Breadth-First Search over de topology-graph om te bepalen hoe ver elke server van het internet verwijderd is. CVE-aanbevelingen worden gesorteerd op cvss_base × exposure_score × epss_probability, waar exposure_score 1.0 is voor internet-facing servers en daalt naarmate de server dieper in de interne architectuur zit.

Blast Radius per server: hoeveel andere systemen worden geraakt als deze gecompromitteerd wordt? Diezelfde score weegt mee in de CVE-prioritering.

Resultaat: de vijf CVEs die je vandaag moet fixen staan bovenaan, niet de vijf met de hoogste CVSS-score.

Process DNA als extra laag: detecteer binary-swaps

Een CVE-scan detecteert bekende kwetsbaarheden in bekende software. Maar wat als een aanvaller een binary vervangt zonder een CVE te introduceren?

Process DNA fingerprinting berekent een SHA256-hash van elke draaiende binary. Als /usr/bin/node plots een andere hash heeft zonder corresponderende package-update, is dat een Critical alert — ongeacht of er een CVE bij hoort.

De integriteit-pagina toont per host welke binaries afwijken van baseline of een bekend manifest.

De twee lagen zijn complementair:

• CVE-matching: detecteert bekende kwetsbaarheden in geïnstalleerde software
• Process DNA: detecteert onbekende wijzigingen aan draaiende binaries

Wat je kunt aantonen aan een auditor

NIS2 artikel 21(2)(d) vereist beveiliging bij verwerving, ontwikkeling en onderhoud van systemen. Supply chain security valt daar rechtstreeks onder.

De audit-pagina aggregeert wat auditors vragen: CVE-tijdlijnen per host, evidence packs, signing chain.

Met een signed evidence pack er bovenop is dat offline verifieerbaar. Niet manueel gereconstrueerd uit Git-commits en deployment-logs, maar automatisch gegenereerd uit live monitoring-data.

Eerlijk over beperkingen

Supply chain security heeft geen perfecte oplossing. Wat monsys detecteert:

• ✓ Bekende CVEs in OS-packages, container-images en application dependencies
• ✓ Binary-wijzigingen via process DNA
• ✓ Zero-day aanvallen die een bekende binary vervangen

Wat monsys niet detecteert:

• ✗ Supply chain-aanvallen die nog geen CVE hebben (zero-day exploits in dependencies)
• ✗ Aanvallen via niet-gescande ecosystemen (Rust cargo, .NET NuGet — roadmap Q3 2026)
• ✗ Aanvallen die volledig in memory opereren zonder disk-wijziging

Voor de laatste categorie zijn honeypot canaries de aanvullende laag: een aanvaller die in memory een canary-bestand leest, triggert alsnog een Critical alert.

Aan de slag

Installeer de agent op een productieserver en wacht 90 seconden. Je krijgt een CVE-overzicht van je dependencies dat je waarschijnlijk nooit eerder gezien hebt. De kans dat er een Critical bij zit die je niet kende: significant.

Eerste vijf servers gratis. Geen creditcard nodig.

---

Supply chain security is gedocumenteerd in docs.monsys.ai/nl/security/supply-chain. Installeer in 30 seconden: monsys.ai/nl/signup.