Supply chain security: why your npm dependencies are more dangerous than you think

In May 2021, the SolarWinds attack infected 18,000 organisations via a software update. In 2022, millions of npm packages were poisoned via the node-ipc library. In 2024 a backdoor sat in xz-utils that was about to land in every major Linux distribution.

Supply chain attacks are effective because they bypass the security perimeter via software you install and trust yourself. And the problem is growing: the average Node.js application has 1,000+ transitive dependencies. Do you know which of them are vulnerable right now?

The scale problem

In a recently monitored production environment (Belgian SMB, ~10 servers with Node.js and Go services), the monsys agent counted:

• 10,854 dependencies across four ecosystems (npm, Go, Packagist, PyPI)
• 1,998 CVE matches after scanning against OSV.dev
• 14 CRITICAL that nobody knew about

These are not hypothetical numbers — that is what was found within 90 seconds after activating the agent.

The problem isn't that developers are bad at security. It's that no one can manually track 10,000+ dependencies. You need automation that scans continuously, not a yearly pentest that takes a snapshot.

Three layers of supply chain risk

monsys covers three different layers:

Layer 1: OS packages

The agent reads dpkg -l, rpm -qa, winget list on every host. The hub matches daily against NVD (National Vulnerability Database) + EPSS (Exploit Prediction Scoring System). EPSS is crucial: a CVE with CVSS 9.8 but EPSS 0.001 (1-in-1000 exploit chance) is less urgent than a CVE with CVSS 7.5 and EPSS 0.34.

Internet-exposed processes (nginx, Apache, Node.js on port 443) get a 1.5× risk factor on top of their CVE score.

Recommendations show what to do today — prioritised by CVSS × exposure × EPSS, not just the CVSS score.

Layer 2: Container images

The agent reports docker ps output — just the image names, no root access required. The hub runs Trivy server-side against each unique image. No Trivy install on the client machine, no extra software, no additional privileges.

Layer 3: Application dependencies

This is the layer most teams miss: the transitive dependencies of your application code.

The agent scans lockfiles on the host: package-lock.json / yarn.lock (npm), requirements.txt / Pipfile.lock (pip), composer.lock (PHP/Packagist), Gemfile.lock (Ruby), go.sum (Go). From each lockfile, (package, version) tuples are extracted. The hub batch-queries OSV.dev per ecosystem.

Important: the agent does not send lockfile content to the hub. Only the parsed (package, version) tuples — the same information npm ls gives anyone with shell access. Your application source never leaves the host.

The inventory page aggregates per host: OS packages, app dependencies, services, users, SSH keys, open ports. Directly clickable to CVE status.

What the timeline looks like in practice

The most compelling argument for continuous scanning is the timeline:

• T+0s — Agent installed on ten production servers
• T+45s — First OSV.dev batch query returns: 1,998 matches
• T+5min — 10,854 dependencies mapped across four ecosystems, linked to project path + risk score
• T+13min — Operator has reviewed all 14 CRITICAL, fix versions sit next to each CVE
• T+17min — First go get -u + redeploy started for three of the fourteen

Compare that with the traditional approach: a pentest that takes three weeks, an eighty-page report that arrives three weeks later, and then a prioritisation discussion that takes another two weeks. The vulnerability has existed for two months by then.

Blast-radius correlation: not every CVE is equally urgent

A Critical CVE on an internal test server is less urgent than a Medium CVE on your load balancer. Blast-radius CVE prioritisation handles that automatically.

The hub runs a Breadth-First Search over the topology graph to determine how far each server is from the internet. CVE recommendations are sorted on cvss_base × exposure_score × epss_probability, where exposure_score is 1.0 for internet-facing servers and decreases as the server sits deeper in the internal architecture.

Blast Radius per server: how many other systems are affected if this one is compromised? That same score weighs into the CVE prioritisation.

Result: the five CVEs you must fix today sit at the top, not the five with the highest CVSS score.

Process DNA as an extra layer: detect binary swaps

A CVE scan detects known vulnerabilities in known software. But what if an attacker replaces a binary without introducing a CVE?

Process DNA fingerprinting computes a SHA256 hash of every running binary. If /usr/bin/node suddenly has a different hash without a matching package update, that's a Critical alert — whether or not a CVE attaches to it.

The integrity page shows per host which binaries deviate from baseline or a known manifest.

The two layers are complementary:

• CVE matching: detects known vulnerabilities in installed software
• Process DNA: detects unknown changes to running binaries

What you can demonstrate to an auditor

NIS2 Article 21(2)(d) requires security in acquisition, development and maintenance of systems. Supply chain security falls squarely under that.

The audit page aggregates what auditors ask: CVE timelines per host, evidence packs, signing chain.

With a signed evidence pack on top, that's verifiable offline. Not manually reconstructed from Git commits and deployment logs, but automatically generated from live monitoring data.

Honest about limitations

Supply chain security has no perfect solution. What monsys detects:

• ✓ Known CVEs in OS packages, container images and application dependencies
• ✓ Binary changes via process DNA
• ✓ Zero-day attacks that replace a known binary

What monsys does not detect:

• ✗ Supply chain attacks that have no CVE yet (zero-day exploits in dependencies)
• ✗ Attacks via unscanned ecosystems (Rust cargo, .NET NuGet — Q3 2026 roadmap)
• ✗ Attacks that operate entirely in memory without disk change

For the last category, honeypot canaries are the complementary layer: an attacker that reads a canary file in memory still triggers a Critical alert.

Getting started

Install the agent on a production server and wait 90 seconds. You'll get a CVE overview of your dependencies you've likely never seen before. The chance there's a Critical you didn't know about: significant.

First five servers free. No credit card required.

---

Supply chain security is documented at docs.monsys.ai/en/security/supply-chain. Install in 30 seconds: monsys.ai/en/signup.