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.
At a glance
What this is: Arnica argues that reachability analysis turns npm triage from dependency counting into live code-path assessment by filtering out vulnerabilities your Node.js application never invokes.
Why it matters: This matters because AppSec and platform teams need to spend review time on exploitable paths, not on the large volume of transitive findings that inflate backlog without changing runtime risk.
By the numbers:
- Reachability analysis can filter out the 85% of findings that exist in node_modules but never execute in an application, according to Arnica.
- The May 2026 Mini Shai-Hulud campaign published 639 malicious npm versions in one hour across 323 packages, according to Arnica.
Context
Node.js dependency management is a governance problem as much as a tooling problem. npm install pulls in direct and transitive packages, so teams often inherit vulnerability records that do not reflect whether the application can actually reach the affected function. In this context, SCA becomes useful only when it separates installed exposure from exploitable exposure.
That distinction matters because modern JavaScript estates move fast across package manifests, CI pipelines, and code ownership models. When vulnerable code sits three or four levels deep in node_modules, the identity of the package owner is less important than whether runtime execution can ever touch the flaw. For AppSec teams, that is the practical boundary reachability analysis tries to define.
Key questions
Q: What fails when SCA tools flag every npm CVE without reachability context?
A: Teams lose triage signal because installed exposure gets treated like exploitable exposure. That creates backlog inflation, wastes patching effort on unreachable code, and delays attention on vulnerabilities that production code can actually invoke. A reachability-aware process keeps the inventory, but it changes the decision point from package presence to call-path evidence.
Q: Why do reachable vulnerabilities matter more than severity scores in Node.js apps?
A: Severity scores describe flaw class and potential impact, but they do not know whether your application can call the vulnerable function. In Node.js estates with deep transitive chains, runtime reachability is the missing context that turns a CVE from theoretical exposure into actionable risk. Without it, Critical and High labels overwhelm the queue.
Q: What are the signs that SCA triage is failing in npm supply chains?
A: Common signs include a backlog full of transitive findings, repeated patching of libraries that never appear in execution traces, and developers ignoring alerts because too many are unreachable. If teams cannot explain which findings are live code paths, they are managing inventory volume instead of exploitability.
Q: How should teams respond when a vulnerable npm package is reachable in production?
A: Prioritise remediation based on execution path, ownership, and external exposure. If the vulnerable function is callable in a production flow, treat it as an active risk, assign it to the current code owner, and verify whether a patch, upgrade, or compensating control can remove the path before the next release.
Technical breakdown
Why dependency inventory creates false positives in npm SCA
Software composition analysis starts with inventory: parse package.json, walk the dependency tree, and match versions against vulnerability databases. That is necessary, but it answers only what is present, not what is callable. In Node.js ecosystems, a transitive package may inherit a CVE that sits behind conditions your application never meets, so the installed component is vulnerable in theory while remaining inert in practice. The result is a findings list that blends exploitable paths with dead code, forcing teams to spend triage effort on issues that cannot be reached at runtime.
Practical implication: treat inventory as an input, not a decision, and add reachability evidence before escalating SCA findings.
How call graphs separate reachable code from installed exposure
Reachability analysis builds a call graph from application entry points through functions in third-party packages. If the graph has a path to the vulnerable function, the finding is reachable; if not, it remains installed exposure without an execution path. This matters because runtime context is what severity scores lack. CVSS can tell you a flaw exists, but it cannot tell you whether your application actually invokes the affected branch. For npm teams, the useful question is not how many CVEs exist in node_modules, but which ones can be exercised by production code.
Practical implication: use call-path tracing to rank vulnerabilities by execution likelihood rather than by package presence alone.
Why reachability still needs threat intelligence and ownership context
Reachability reduces noise, but it does not replace broader supply chain judgement. A package can be reachable today, then become more urgent when threat intelligence changes, a vulnerability enters CISA's KEV catalog, or a patch becomes available. The operational challenge is then ownership: findings must route to the current code owner, not the historical commit author, especially in teams with high developer turnover. That is where reachability, backlog management, and ownership graphs intersect. The control question is no longer just whether the flaw is reachable, but who is accountable for remediation now.
Practical implication: pair reachability with current code-owner routing and threat-intel re-evaluation so findings do not stall in dead inboxes.
Threat narrative
Attacker objective: The attacker objective is to get malicious or vulnerable code accepted into the software supply chain and buried in noisy findings so real exposure is harder to prioritise.
- Entry occurs through the npm ecosystem when teams pull in direct and transitive dependencies that may carry vulnerable or malicious code.
- Credential or code-path abuse happens when security tooling treats every installed CVE as equally actionable, even when the vulnerable function is not called by the application.
- Impact is triage overload, delayed remediation of genuinely reachable flaws, and blind spots when supply chain compromises introduce malicious packages that require separate provenance controls.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Reachability analysis exposes the real boundary between inventory and exploitability. Software teams have long treated dependency listing as if it were a risk decision, but installed exposure and callable exposure are different problems. In npm-heavy estates, that distinction is what determines whether AppSec is measuring backlog or actual attack surface. Practitioners should use reachability to convert noisy vulnerability inventories into execution-based priority lists.
The biggest governance failure in SCA is assuming severity equals urgency. CVSS remains useful for standardisation, but it is context-free by design. When teams elevate every Critical finding in node_modules, they dilute attention across unreachable code and delay response on flaws that actually sit on live code paths. Practitioners should anchor remediation decisions to runtime reachability, not to score inflation.
Supply chain compromise and reachable vulnerability triage are related but not interchangeable problems. The May 2026 npm campaigns show that malicious packages can arrive without any prior CVE record, which means reachability analysis must sit beside provenance and threat-intelligence controls. The field needs both exploitability filtering and package-trust governance. Practitioners should avoid treating reachability as a standalone supply chain defence.
Current owner routing is now part of vulnerability governance, not just workflow hygiene. Arnica's benchmark that most findings were authored by departed developers reflects a common identity problem in engineering operations: code ownership changes faster than alert routing. When ownership graphs are stale, even the right finding lands in the wrong inbox. Practitioners should align reachability triage with live code-owner identity, not historical authorship.
Reachability creates a more defensible SCA programme because it narrows what the organisation is accountable for remediating. That does not mean the rest of the dependency tree is safe, only that teams can separate present exploitability from background library risk. This is a better fit for engineering governance and for board-level reporting that needs a credible measure of actionable exposure. Practitioners should report reachable findings as the primary remediation set and track unexploitable exposure separately.
From our research library:
- Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
- Read next: Financial Services Identity Security Guide
What this signals
Reachability analysis is now the more defensible way to separate active npm risk from background dependency noise. Teams that still triage by CVE count alone are optimising for volume reduction, not exploit reduction. The practical shift is to make runtime call paths the first filter in AppSec prioritisation, then keep provenance checks for malicious package campaigns.
npm supply chains now require two control planes, not one. Reachability answers whether code can be invoked, while provenance and ownership controls answer whether the package should have been trusted and who should fix it. That combination is where modern SCA programmes become operational rather than purely informational.
For practitioners
- Implement reachability-based triage for npm findings Trace application entry points to vulnerable functions so teams can suppress findings that are installed but not callable in the running codebase.
- Separate exploitable exposure from inventory exposure Create two queues, one for reachable vulnerabilities and one for background dependency risk, so remediation time tracks execution paths instead of package counts.
- Re-evaluate findings when threat intelligence changes Reopen reachable findings when a CVE enters KEV, EPSS shifts materially, or a patch lands, because urgency can change even when the code path does not.
- Route alerts to current code owners Replace stale git-author routing with an identity graph or ownership map so findings reach the developer or team that actually maintains the package today.
- Treat malicious package campaigns as a separate control problem Use provenance, package vetting, and repository trust controls for attacks that ship malicious code, because reachability does not neutralise a poisoned dependency.
Key takeaways
- Node.js dependency trees can produce many vulnerabilities that are visible to scanners but irrelevant to runtime exploitability.
- Reachability analysis changes SCA from package inventory review into execution-path prioritisation, which reduces noise and focuses remediation.
- AppSec teams still need provenance and ownership controls alongside reachability because malicious packages and stale routing are separate governance problems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | npm dependency use is unsafe consumption of third-party code and trust boundaries. |
| Recommendation — Review third-party package consumption paths and limit dependency trust to what runtime actually uses. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article's supply-chain attack examples centre on stolen secrets and downstream abuse. |
| Recommendation — Map npm supply-chain abuse to credential access and exfiltration behaviours in your detections. | ||
| CIS Controls v8 | CIS-18 — Application Software Security | SCA triage and dependency governance sit inside application software security practices. |
| Recommendation — Use application software security controls to prioritise reachable findings over raw dependency counts. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit | Dependency reachability helps reduce exposure from software paths that move data through runtime flows. |
| Recommendation — Apply data protection and software governance controls to runtime paths that can actually be executed. | ||
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.
- 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.
- 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.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. If your programme also has to govern secrets, machine identities, and access paths, the course helps connect those controls to operational reality.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org