Notifications
Clear all
Topic starter
02/08/2026 11:27 am
TL;DR: Transitive reachability analysis creates too much noise to be operationally useful, because static analysis and deep dependency chains produce findings that are often theoretically reachable but not practically exploitable, according to Semgrep. The real decision point is prioritisation, not broader detection coverage, because teams need vulnerabilities they can remediate with confidence.
NHIMG editorial — based on content published by Semgrep: Transitive reachability analysis in software supply chain security
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: What breaks when transitive dependency analysis is treated as a remediation priority on its own?
A: Teams end up fixing findings that look reachable in a call graph but are not exploitable in production.
Q: Why do deep dependency trees make software supply chain triage harder?
A: Because each nested library adds more possible code paths, configuration states, and parent-package dependencies that static tools must reason about.
Q: How do security teams know if transitive reachability findings are actually useful?
A: Useful findings can be tied to a deployed code path, a real request flow, or a configuration state that exists in production.
Practitioner guidance
- Prioritise reachable findings with runtime evidence Require production configuration, feature flag, and request-path evidence before escalating transitive dependency alerts into remediation work.
- Map vulnerable packages to affected repositories Use dependency search and SBOM data to identify every repository, pipeline, and release artifact that includes the affected package chain.
- Separate theoretical exposure from fixable exposure Create triage rules that distinguish code paths that exist in static graphs from paths that are actually reachable in deployed environments.
What's in the full article
Semgrep's full post covers the operational detail this post intentionally leaves for the source:
- Semgrep's explanation of how its static analysis engine differs from call graph based transitive reachability.
- Examples of direct dependency prioritisation, license compliance, SBOM generation, and dependency search in practice.
- The article's discussion of Path-to-Transitivity and how Semgrep plans to make transitive findings more actionable.
👉 Read Semgrep's analysis of transitive reachability and supply chain triage →
Transitive dependency risk: what security teams can actually fix?
Explore further
02/08/2026 12:43 pm
Transitive reachability creates a prioritisation problem, not just a visibility problem. More dependency insight does not automatically produce better security outcomes when the majority of alerts are too distant from runtime reality to act on. The operational test is whether a team can explain exploitability, isolate blast radius, and fix the issue without introducing new defects. For supply chain security, the useful question is not how many packages are reachable, but which findings change risk in a material way.
A question worth separating out:
Q: What should teams do when transitive dependencies are vulnerable but difficult to patch directly?
A: Use package inventory, SBOMs, and repository search to identify where the dependency is used, then decide whether to patch the parent package, replace it, or reduce exposure through configuration and compensating controls. The right answer depends on whether the vulnerable path exists in production and whether the remediation introduces more risk than it removes.
👉 Read our full editorial: Transitive reachability analysis still misses the vulnerabilities teams can act on
