Reachability analysis in SCA cuts alert noise and focuses triage

At a glance

What this is: This is an analysis of how reachability changes SCA from package-level alerting to code-aware exploitability assessment.

Why it matters: It matters because AppSec teams, security architects, and developers need fewer false positives and better prioritisation when deciding which dependency issues justify urgent remediation.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Semgrep's whitepaper on reachability analysis in SCA

Context

Software composition analysis is supposed to help teams decide which third-party component risks matter, but version-based findings alone often produce too much noise. Reachability analysis addresses that governance gap by asking whether application code actually touches the vulnerable path, which is a more accurate way to prioritise AppSec work and reduce triage drag.

The reachability question is especially relevant to identity and secret governance when dependency issues intersect with exposed credentials, dataflow into security-sensitive functions, or automation that expands the blast radius of a vulnerable package. In that sense, code-aware SCA is not just a vulnerability management refinement, but a control on how teams decide what deserves developer time and operational urgency.

Key questions

Q: How should AppSec teams prioritise SCA findings when reachability is available?

A: Prioritise findings that are not only present in a dependency list but also confirmed by function-level or dataflow evidence. That approach reduces false positives and focuses engineers on paths an attacker could realistically trigger. Use version-only findings as a starting point, not as a final severity signal.

Q: Why does dataflow reachability matter more than dependency presence alone?

A: Because dependency presence only proves that code exists in the build, not that an exploitable path exists. Dataflow reachability shows whether untrusted or risky input can actually reach the vulnerable call, which is much closer to real exploitability and therefore much more useful for triage decisions.

Q: What do security teams get wrong about function-level reachability?

A: They often assume that a called vulnerable function is automatically urgent. In practice, the context of the call matters, especially when inputs are fixed, constrained, or otherwise not attacker-controlled. Without dataflow analysis, teams can still overprioritise low-risk issues.

Q: When should teams treat a dependency finding as an immediate incident rather than routine remediation?

A: When the package is known to be malicious, compromised, or intentionally designed to harm the build or runtime environment. In that case, reachability is secondary because the package itself is part of the attack path. The right response is containment, provenance review, and removal from the pipeline.

Technical breakdown

Dependency reachability versus true exploitability

Dependency reachability only checks whether a package is present in the build or import graph. That is useful as a first filter, but it does not answer whether the vulnerable code path is ever executed. In SCA, that distinction matters because package presence can create many false positives, while actual exploitability depends on runtime use, call paths, and whether the application ever touches the affected component.

Practical implication: use dependency reachability only as a broad triage layer, not as the basis for final remediation decisions.

Function-level reachability and vulnerable call paths

Function-level reachability goes deeper by tracing whether the application invokes a vulnerable function at all. This reduces noise because imported libraries often contain many unused functions, and only a subset may matter. However, it still treats every call as equally risky, even when the call is made with fixed inputs or in a constrained context that does not meaningfully expose the flaw.

Practical implication: pair function-level results with code review so teams do not overreact to calls that are technically reachable but operationally low risk.

Dataflow reachability and exploitable input paths

Dataflow reachability traces whether untrusted or risky data can actually flow into a vulnerable function. That is the closest of the three models to exploitability because it links the presence of a flaw to a realistic attack path. If user-controlled input, secrets, or other sensitive values can influence the call, the finding deserves much higher priority than a static or inert invocation.

Practical implication: prioritise dataflow-based findings first, especially where application input can influence security-sensitive library behaviour.

Threat narrative

Attacker objective: The attacker wants to convert a dependency finding into a usable exploit path by finding code that actually reaches the vulnerable function with risky input.

1. Entry occurs when an attacker identifies a vulnerable dependency in an application but only has a viable path if the affected function is actually invoked.
2. Escalation follows when code paths and dataflow conditions line up, allowing the attacker to reach the flaw with attacker-controlled input.
3. Impact occurs when the vulnerable path is exploitable in practice, turning a noisy dependency alert into real application compromise or data exposure.

NHI Mgmt Group analysis

Reachability analysis is a governance filter, not just a scanning feature. Traditional SCA treats vulnerability presence as equivalent to remediation priority, which creates alert fatigue and weakens trust in AppSec tooling. Reachability changes the governance question from "what is known" to "what is actually exposed", and that is the more defensible basis for triage. For AppSec programmes, the practical conclusion is that code-aware prioritisation is now a control issue, not merely a productivity improvement.

Dataflow reachability is the point where AppSec starts to approximate exploitability. Function calls alone are too blunt because they ignore how inputs behave inside the application. Once untrusted data can influence a vulnerable call, the finding becomes materially different from a static or inert dependency. Teams that cannot distinguish those paths will keep spending remediation effort on low-value findings while real risk stays buried.

Secrets and dependency governance overlap more than many teams assume. Vulnerable packages matter most when they intersect with credential handling, token flow, or code paths that process sensitive values. That makes reachability analysis relevant to NHI governance because service tokens, API keys, and other secrets often sit inside the same codebase as third-party dependencies. The named concept here is exploitability drift: the widening gap between a dependency being present and a dependency being exploitable. Teams should treat that gap as a measurable governance problem.

Malicious dependency classification needs a different response model than ordinary vulnerability triage. If a package is itself designed to compromise systems, then the question is not whether a specific vulnerable function is reachable, but whether the package should exist in the environment at all. That changes the control objective from selective remediation to immediate containment, provenance review, and build pipeline validation. The practitioner conclusion is simple: use reachability for prioritisation, but do not let it dilute response to known malicious packages.

What this signals

Exploitability drift will become a more important AppSec metric as teams move from volume-based vulnerability reporting to code-aware prioritisation. The practical test is whether your programme can distinguish a dependency that exists from a dependency that can actually be reached, and whether remediation SLAs reflect that distinction.

Reachability analysis also reinforces a broader identity and access lesson: inventory without context is not governance. When application code, secrets, and third-party packages intersect, teams need both software control and identity control to understand where real exposure exists. For identity-heavy environments, the same logic applies to OAuth-connected apps and NHI lifecycle visibility, which is why The State of Non-Human Identity Security remains relevant.

For practitioners

• Separate noisy findings from exploitable ones Use dependency-level results only as a first pass, then require function-level or dataflow evidence before escalating remediation priority. This stops teams from burning cycles on packages that are present but never executed.
• Tune SCA workflows to code paths, not version lists Route findings into triage queues based on whether the vulnerable function is called and whether untrusted input reaches it. That gives developers a clearer fix list and reduces security-development friction.
• Escalate malicious dependency findings immediately Treat dangerous packages or compromised versions as a separate class from ordinary reachability findings. If the package itself is malicious, remove it from the build and validate source provenance before any further release.
• Use reachability to improve remediation economics Focus patching on reachable, exploitable paths first, then measure whether alert volumes and mean time to remediate are improving. This creates a repeatable signal for whether your SCA programme is becoming more useful.

Key takeaways

• Reachability analysis helps AppSec teams separate dependency noise from code paths that are actually exposed.
• Dataflow-aware SCA is the closest of the three models to real exploitability because it traces attacker-relevant input paths.
• Teams should use reachability to prioritise routine vulnerabilities, but handle malicious dependencies as an immediate containment issue.

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.
• 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.
• Malicious dependency: A malicious dependency is a package or version that is inherently dangerous because it is designed to compromise systems or has been intentionally tampered with. Unlike ordinary vulnerabilities, these findings usually require immediate removal or containment rather than risk-based scheduling.

What's in the full article

Semgrep's full whitepaper covers the operational detail this post intentionally leaves for the source:

• Side-by-side comparisons of dependency-level, function-level, and dataflow reachability in real scanning workflows.
• Performance benchmarks that show how scan speed changes when static analysis is pushed deeper into code paths.
• Implementation considerations for teams evaluating code-aware SCA without overwhelming developers with false positives.
• Examples of how Semgrep uses static analysis to differentiate reachable-but-safe from reachable-and-exploitable paths.

👉 The full Semgrep whitepaper covers scan speed trade-offs, exploitability examples, and implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management in practical terms. It is designed for practitioners who need to connect identity controls to broader security operations and governance decisions.