Notifications
Clear all
Topic starter
18/08/2026 2:46 pm
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
18/08/2026 3:29 pm
Reachability is becoming the missing control layer in AppSec triage. Inventory tools tell teams what is present, but not what is executable, and that gap produces governance fatigue. In large npm estates, the difference between installed and reachable code is where remediation effort should be concentrated. Practitioners should treat exploitability evidence as a prioritisation control, not just a reporting enhancement.
A question worth separating out:
Q: How do teams respond when a supply chain attack affects a trusted npm package?
A: Contain by validating package provenance, reviewing build outputs, and checking whether compromised code reached production or was only installed. Then reassess exposure using runtime evidence, because malicious package attacks are not solved by reachability alone and may require broader dependency hygiene.
👉 Read our full editorial: Reachability analysis is reshaping SCA triage for Node.js teams
