Reachability analysis in npm supply chains: what changes for AppSec?

TL;DR: Node.js supply chains can surface hundreds of transitive CVEs that are never actually callable, and Arnica argues reachability analysis cuts SCA findings by over 85% by tracing live code paths rather than listing every installed vulnerability. That shift matters because exploitable exposure, not package inventory, is what should drive AppSec prioritisation.

NHIMG editorial — based on content published by Arnica: Security 101 SCA: Prioritizing Reachable Vulnerabilities

By the numbers:

• Reachability analysis cuts SCA findings by over 85% by tracing call graphs to filter out vulnerabilities in code paths your application never invokes.
• The Mini Shai-Hulud campaign published 639 malicious npm versions in one hour across 323 packages.
• Arnica says 82% of findings were originally authored by developers who had already left the company.

Questions worth separating out

Q: How should AppSec teams prioritise npm vulnerabilities when most findings are not exploitable?

A: Prioritise based on reachability, not raw CVE volume.

Q: Why do transitive dependencies create so much triage noise in Node.js applications?

A: Because each package can bring in multiple nested packages with their own CVEs, and tools usually report all of them.

Q: What do security teams get wrong about high CVSS scores?

A: They often treat CVSS as a complete ranking signal.

Practitioner guidance

• Adopt reachability-based triage for npm findings Require SCA workflows to prove a call path from application entry points to a vulnerable function before routing the issue as high priority.
• Separate exploitable CVEs from package inventory noise Keep full dependency inventory for audit purposes, but maintain a second queue that only includes vulnerabilities reachable in the current runtime context.
• Re-route alerts to current code owners Use repository identity graphs or ownership metadata so findings land with the team that owns the code today, not the original commit author.

What's in the full article

Arnica's full blog post covers the operational detail this post intentionally leaves for the source:

• Function-level reachability logic for distinguishing callable vulnerabilities from inherited CVEs in npm dependencies
• Continuous backlog re-evaluation logic tied to new threat intel, patch availability, and advisory changes
• Identity-graph routing patterns for assigning findings to current code owners instead of departed developers
• Plain-English prompt tuning examples for adjusting triage behaviour across products

👉 Read Arnica's analysis of SCA reachability and npm supply chain risk →

Reachability analysis in npm supply chains: what changes for AppSec?

Explore further

View Full Forum →  |  NHI Foundation Course →