Notifications
Clear all
Topic starter
02/08/2026 12:12 pm
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.
NHIMG editorial — based on content published by Semgrep: Reachability Analysis in SCA and the risks that actually matter
Questions worth separating out
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.
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.
Q: What do security teams get wrong about function-level reachability?
A: They often assume that a called vulnerable function is automatically urgent.
Practitioner guidance
- 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.
- 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.
- Escalate malicious dependency findings immediately Treat dangerous packages or compromised versions as a separate class from ordinary reachability findings.
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.
👉 Read Semgrep's whitepaper on reachability analysis in SCA →
SCA reachability analysis: what it means for AppSec teams?
Explore further
02/08/2026 1:15 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Reachability analysis in SCA cuts alert noise and focuses triage
