TL;DR: Reachability analysis in Software Composition Analysis separates vulnerable dependencies that are merely present from those that are actually callable or exploitable, according to Semgrep. That shift matters because dependency-level scanning alone drives alert fatigue, slows remediation, and weakens developer trust in AppSec tooling.
At a glance
What this is: This is an analysis of reachability-based software composition scanning, which shows why package presence alone is a weak proxy for exploitability and why deeper analysis can reduce false positives.
Why it matters: It matters because AppSec and engineering teams need to prioritise real application risk, reduce noisy vulnerability queues, and preserve developer trust in security tooling.
Context
Software composition analysis becomes noisy when it treats dependency presence as equivalent to application exposure. The practical gap is between knowing a vulnerable package exists in a build and knowing whether the vulnerable code path can actually be reached by execution, which is the difference between inventory and exploitability.
That distinction matters in both application security and identity-adjacent governance because automated controls are only useful when they reflect how software really behaves. For teams managing supply chain risk, the question is not whether a library contains a flaw, but whether the application can invoke the flawed behaviour in a way that changes real risk.
Reachability analysis tries to close that gap by tying findings to code paths, function calls, and dataflow rather than package versions alone. In practice, that makes triage more defensible and reduces the tendency for teams to mute or ignore broad SCA alerts.
Key questions
Q: How should AppSec teams use reachability to cut noisy SCA alerts?
A: Use reachability to separate dependencies that are merely present from code paths that can actually invoke the vulnerable behaviour. Start with dependency reachability for inventory, then escalate only those findings that show function calls or dataflow into the risky sink. That keeps remediation focused on exploitable exposure instead of package counts.
Q: Why does function-level reachability still leave triage uncertainty?
A: Because a function being called does not prove that an attacker can influence it in a harmful way. The call may use static inputs, constrained parameters, or safe execution conditions that remove real exploitability. Teams need contextual analysis, especially dataflow into the vulnerable operation, before treating the finding as priority one.
Q: What breaks when SCA tools treat every vulnerable dependency as equally important?
A: Teams get overloaded with alerts, patch cycles slow down, and developers learn to ignore security output that does not match application reality. The result is not just noise, but lower trust in AppSec tooling and weaker remediation discipline. That is why exploitability-aware prioritisation matters.
Q: When should teams prioritise malicious dependency findings over reachability analysis?
A: Immediately, when the package itself is known to be compromised or intentionally dangerous. In that case, the risk is not limited to a vulnerable function path. The dependency should be treated as unsafe on presence alone, while reachability remains useful for understanding broader exposure patterns.
Technical breakdown
Dependency reachability only proves presence, not exposure
Dependency reachability is the shallowest form of analysis. It confirms that an application imports or includes a package, but it does not establish whether the vulnerable code path is ever invoked. That is why version-based SCA often produces findings that are technically true yet operationally misleading. A package can be installed, imported, or bundled without the application ever touching the affected function. In security terms, presence is a supply chain fact, not an exploitability finding.
Practical implication: Treat dependency reachability as a screening layer, not a final risk decision, and require deeper analysis before escalating remediation.
Function-level reachability narrows the noise, but still misses context
Function-level reachability asks a better question: is the vulnerable function actually called? That moves analysis closer to the execution path and filters out many false positives. But call presence still does not tell you whether the call is dangerous in practice. A vulnerable function invoked with static or constrained inputs may not present meaningful attacker leverage, even though it is technically reachable. The remaining blind spot is context, especially whether untrusted data can influence the call in a harmful way.
Practical implication: Use function-level results to prioritise review, but do not equate a call graph hit with a confirmed exploitable issue.
Dataflow reachability is what turns reachability into exploitability
Dataflow reachability follows the path of inputs into a vulnerable function and asks whether risky or untrusted data can influence the sensitive operation. That is the closest of the three approaches to an exploitability judgment because it connects code usage to attacker-controlled inputs. This is where static analysis becomes more operationally useful: it can separate reachable-but-safe code from reachable-and-exploitable code. The difference matters most for remediation queues, because teams need to know which findings merit immediate action and which can remain on watch.
Practical implication: Prefer tools that trace dataflow into vulnerable sinks when you need SCA findings that align with real application risk.
Threat narrative
Attacker objective: The attacker objective is to exploit only the dependency paths that the application actually reaches, not the vulnerabilities that merely appear in inventory.
- Entry occurs when a vulnerable dependency is present in the application build, but presence alone does not prove the code path is reachable.
- Credential access is not the issue here; the relevant failure is that scanners may mark non-invoked vulnerable functions as actionable despite no execution path.
- Escalation happens when teams spend triage time on unreachable findings and delay fixes for genuinely exploitable paths.
- Impact is alert fatigue, slower patch cycles, and reduced trust in AppSec tooling, which weakens remediation discipline.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
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 is a governance control, not just a scan feature. Security teams often discuss SCA noise as a tooling limitation, but the deeper issue is control quality. If a finding cannot distinguish inventory from execution, it does not support reliable prioritisation, and governance begins to drift toward bulk alerting instead of risk management. Practitioners should treat reachability as part of the decision standard for remediation.
OWASP Cheat Sheet Series style application context improves SCA triage. The important question is whether the vulnerable code path is actually usable in the application’s runtime context, not whether the package exists in a manifest. That aligns with static analysis principles and helps AppSec teams avoid treating dependency presence as proof of exposure. Practitioners should tie package alerts to call paths and input influence before escalating.
Alert fatigue becomes a supply chain trust problem when noise stays unresolved. Teams that repeatedly surface non-actionable dependency findings create the conditions for developer disengagement and security exception culture. In that state, the tool is still reporting, but the programme is no longer learning. Practitioners should measure whether their SCA process is reducing false positives and strengthening developer confidence.
Reachability creates a better boundary between AppSec and engineering ownership. When findings are mapped to actual usage, developers can focus on code that matters and security teams can reserve escalation for exploit-relevant cases. That is the operational value of reachability: it lets governance follow execution rather than package metadata. Practitioners should use it to make remediation queues materially smaller and more defensible.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
What this signals
Reachability analysis is most useful when it changes the remediation queue, not when it merely adds another report view. Teams should expect their SCA process to become smaller, sharper, and easier to defend when findings are tied to execution paths instead of inventory alone. That is the operational threshold that separates useful analysis from alert inflation.
Developer trust in AppSec tooling depends on the tool matching runtime reality. If alerts keep surfacing for code paths that cannot be reached, teams will eventually discount the scanner itself. The programme signal is clear: move triage closer to exploitable code paths or accept weaker adoption over time.
For practitioners
- Adopt dataflow-aware SCA triage Use reachability results that trace untrusted data into vulnerable functions, not just package version matches, to decide which findings deserve remediation.
- Separate dependency presence from exploitability Require a distinct review step for findings that are merely present in the manifest versus findings that are actually callable in the code path.
- Tune SCA workflows for false-positive reduction Measure how many alerts are dismissed after code review and use that data to justify deeper analysis or different scan modes.
- Prioritise dangerous packages immediately Escalate known malicious or compromised dependencies as urgent even before reachability analysis, because the package itself is the risk.
Key takeaways
- Reachability analysis matters because package presence alone is too blunt to represent actual application exposure.
- The strongest SCA programs distinguish inventory findings from callable and data-influenced code paths.
- Teams that use exploitability-aware triage can reduce false positives, speed remediation, and preserve developer trust.
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 NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | Unsafe consumption patterns resemble the trust problem in vulnerable package calls and dataflow. |
| Recommendation — Review consumption paths for risky third-party inputs and block unsafe call patterns before they reach production. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article discusses exploitability paths and downstream impact, which map to attacker misuse of reachable code. |
| Recommendation — Map reachable vulnerable paths to attacker techniques and prioritise the ones that can be exercised from untrusted input. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and recorded | SCA reachability refines how vulnerability information is identified and prioritised. |
| Recommendation — Use reachability to improve vulnerability identification so recorded findings reflect actual application exposure. | ||
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.
- Dependency Reachability: Dependency reachability is the question of whether a vulnerable library or function can actually be invoked in the deployed application path. It matters because not every disclosed package flaw creates equal risk. Teams use it to separate theoretical exposure from issues that can be exploited in practice.
- Function-level reachability: Function-level reachability is the ability to determine whether a vulnerable code path can be executed in the current runtime state. It helps security teams separate theoretical exposure from issues that an attacker can actually invoke in production.
- Dataflow reachability: Dataflow reachability traces whether untrusted or risky input can flow into a vulnerable function. It is the most security-relevant of the common SCA reachability models because it links code presence to a realistic attack path and therefore improves exploitability judgments.
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. Explore it if your programme needs a stronger identity lens on access, privilege, and lifecycle governance.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org