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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “What You Should Know About Dependency Reachability in SCA”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Reachability analysis matters because package presence alone is too blunt to represent actual application exposure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Reachability analysis in SCA cuts alert noise and focuses triage