Reachability analysis is reshaping SCA triage for Node.js teams

At a glance

What this is: This is an AppSec analysis of why software composition analysis alone overstates risk in npm-heavy applications and how reachability analysis filters findings down to callable code paths.

Why it matters: It matters because security and identity practitioners need triage models that distinguish inherited noise from exploitable exposure, especially where code ownership, secrets, and pipeline trust affect remediation speed.

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.

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

Context

Node.js dependency trees create a security governance problem because traditional SCA inventories packages without proving whether vulnerable code is actually callable in the running application. In npm-heavy environments, that produces a backlog of findings that may be technically real but operationally irrelevant, which dilutes attention from the exposures that can actually be reached and abused.

This article is also about a broader trust issue in software supply chains: the same ecosystem that speeds delivery can hide malicious packages, orphaned ownership, and stale findings. For teams that already manage secrets, service accounts, and CI/CD access, reachability context becomes part of the evidence needed to decide what is worth remediating first.

The article’s starting position is typical of modern AppSec programmes that have good inventory but weak exploitability filtering.

Key questions

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

A: Prioritise based on reachability, not raw CVE volume. Treat a finding as urgent only when the vulnerable function sits on a real call path from application entry points. Keep inventory coverage for compliance, but route engineering effort to code that can actually execute in the current runtime.

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. Most of those nested issues are inherited, not intentionally chosen, so the backlog grows faster than teams can evaluate it unless they filter by execution path and ownership.

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

A: They often treat CVSS as a complete ranking signal. In practice, a lower-scored issue can be more dangerous if it is reachable, chained to other weaknesses, or linked to exposed credentials. Teams should look at real attack paths, not just the score attached to an individual finding.

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.

Technical breakdown

Why npm audit creates noise in transitive dependency trees

npm audit checks the full dependency tree against vulnerability databases and reports every matching CVE, regardless of whether the vulnerable function is ever used. In JavaScript applications, that means nested packages three or four layers deep can dominate the backlog even when they are unreachable from application entry points. The result is a triage problem, not just a detection problem, because teams spend time proving negatives instead of fixing exploitable exposure.

Practical implication: prioritise findings that can be reached from live application entry points, not every CVE found in node_modules.

How call graph tracing changes SCA from inventory to exploitability

Reachability analysis builds a call graph by mapping function-to-function relationships across first-party code and dependencies, then tracing whether a vulnerable function sits on a real execution path. If no path exists from application entry points to the flagged code, the issue is classified as unreachable in that runtime context. This does not erase the vulnerability from the package record, but it changes its operational significance from immediate remediation to monitored exposure.

Practical implication: use call-graph evidence to separate theoretical package exposure from code paths that can actually be executed.

Why supply chain attacks still require controls beyond reachability

Reachability analysis helps with known CVEs, but it does not stop malicious package publication, maintainer account takeover, or injected code that has no prior vulnerability record. Attacks like the Mini Shai-Hulud campaign show that package provenance, account security, and runtime monitoring still matter when the artifact itself is the threat. In other words, reachability reduces noise, while provenance and behavioural controls reduce trust in compromised dependencies.

Practical implication: pair reachability scoring with provenance checks, maintainer protection, and runtime detection for malicious package behaviour.

Threat narrative

Attacker objective: The attacker wants trusted distribution into downstream builds, either to execute malicious code or to mask higher-risk supply chain compromise inside noisy dependency trees.

1. Entry occurs when an attacker gains control of a maintainer account or publishes a malicious npm package into a trusted dependency ecosystem.
2. Escalation happens as transitive dependencies are pulled into builds and reach production without code review catching the malicious change.
3. Impact follows when malicious package code executes in application runtime or when security teams are overloaded by findings that obscure the real exposure surface.

NHI Mgmt Group analysis

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.

Transitive dependency risk is now a dependency governance problem, not just a vulnerability problem. The article shows how deep package chains turn the software supply chain into an ownership issue as much as a scanning issue. That matters because unowned or departed-code findings slow response even when the flaw is real. Teams should align package visibility, code ownership, and escalation routing before the backlog becomes unmanageable.

Malicious package campaigns prove that vulnerability scoring alone is insufficient. CVSS can describe severity, but it cannot distinguish a known flaw from a trusted package that has been weaponised. This is where supply chain hygiene, provenance verification, and execution monitoring intersect with software composition analysis. Practitioners should assume that some of the highest-risk events will arrive without a CVE at all.

Reachability filtering changes the economics of remediation more than the mechanics of detection. The operational value is not only fewer alerts, but better decision quality for engineering and security teams. When programmes reduce false prioritisation, they free capacity for secrets handling, dependency provenance, and ownership hygiene. Practitioners should measure whether noise reduction is translating into faster closure of actually exploitable issues.

What this signals

Reachability-based prioritisation will matter more as dependency trees continue to grow and security teams are forced to justify every remediation hour. The practical signal for AppSec leaders is whether noisy SCA output is shrinking enough to improve closure rates on genuinely exploitable issues.

Exploitability filtering: the next maturity step is not more scanning, but better evidence about whether a vulnerability can be executed in the deployed application. That is especially relevant where repository ownership, build provenance, and service account access determine who can act on the finding.

For identity programmes, the adjacent lesson is that software supply chains still depend on governed human and non-human access, including maintainer accounts, CI/CD identities, and code-owner routing. When those identities are weakly controlled, vulnerability management and supply chain integrity both degrade.

For practitioners

• 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.
• Pair reachability with provenance controls Track maintainer account security, package signing, and build provenance alongside reachability because malicious package publication can bypass CVE-based filtering.
• Reassess historical findings when threat context changes Re-open or escalate dormant issues when new exploit intelligence, advisory data, or package compromise signals change the risk profile.

Key takeaways

• Reachability analysis changes SCA from a raw inventory of CVEs into a decision model for exploitable risk.
• The article shows that transitive dependency noise, not just vulnerability volume, is what exhausts AppSec teams.
• Provenance controls, code ownership routing, and runtime evidence are still necessary because malicious packages can bypass CVE-based filtering.

Key terms

• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Transitive Dependency: A package that is included indirectly through another package rather than chosen explicitly by a developer. These dependencies often carry their own vulnerability history and can significantly expand the attack surface of an application.
• Call Graph: A map of which functions call which other functions in an application and its dependencies. Security tools use it to trace whether a vulnerable function sits on a live execution path or remains unreachable in practice.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.

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

👉 The full Arnica post covers call-graph filtering, ownership routing, and backlog re-evaluation details

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It gives identity and security practitioners a practical base for controlling access, ownership, and lifecycle risk across modern delivery pipelines.