Transitive reachability analysis still misses the vulnerabilities teams can act on

At a glance

What this is: This is an analysis of why transitive reachability analysis often produces findings that are hard to act on in software supply chain security.

Why it matters: It matters because security, DevSecOps, and application teams need triage signals that map to real exploitability, not just deeper dependency visibility that increases backlog pressure.

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.

👉 Read Semgrep's analysis of transitive reachability and supply chain triage

Context

Transitive supply chain vulnerability analysis is meant to reduce noise by showing whether a vulnerable package is actually used in a way that matters. In practice, the further a dependency sits from application code, the harder it becomes to decide whether a finding is exploitable, remediable, or worth the engineering cost.

This is especially relevant where software supply chain security intersects with identity and secrets governance. Vulnerable packages often sit alongside API keys, build tokens, and service credentials in CI/CD and source control, so the real issue is not only code risk but the trust boundary around non-human identities and the systems that use them. For lifecycle and offboarding context, see the NHI Lifecycle Management Guide.

Key questions

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. That creates alert fatigue, wastes engineering time, and can crowd out vulnerabilities that actually have a clear path to impact. The control problem is not visibility alone, but validation that separates theoretical from actionable exposure.

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. The result is more uncertainty about whether a vulnerable function can actually be invoked. Teams should prioritise package chains with direct runtime use, not simply the deepest or loudest alerts.

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. If the alert cannot be connected to those conditions, it is probably a triage signal rather than a fix-now issue. Measure usefulness by how often a finding leads to a concrete remediation decision.

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.

Technical breakdown

Why transitive reachability analysis becomes noisy in deep dependency trees

Reachability analysis asks whether application code can call a vulnerable function. That works reasonably well for direct dependencies, where call paths are visible and relatively stable. Transitive dependencies change the problem: nested libraries introduce many more possible paths, but static analysis must still assume branches and conditions that may never execute. The result is a large set of theoretically reachable findings that are not always operationally meaningful. In supply chain security, this creates triage debt rather than clarity.

Practical implication: prioritise findings by exploit context and runtime exposure, not by dependency depth alone.

Static analysis versus runtime context in supply chain security

Static analysis examines code without running it, which gives broad coverage but limited certainty. In transitive reachability, that limitation is amplified because tools may mark a vulnerability as reachable even when the relevant parameter values, feature flags, or runtime conditions never occur in production. Semgrep notes that AST-based analysis can inspect how parameters are used more precisely than simple call graph approaches, but even stronger static methods still cannot fully replace runtime evidence. The key distinction is between theoretical reachability and actionable exploitability.

Practical implication: combine static findings with package usage evidence, configuration review, and production telemetry before escalating remediation.

How SBOMs, dependency search, and license compliance fit the operational model

The article argues that teams get more value from capabilities that reduce response time and improve governance, such as dependency search, SBOM generation, and license compliance controls. These functions do not answer every reachability question, but they do help teams locate affected repositories, map package usage, and support audit procedures. That is a different security objective from transitive reachability. One is about coverage and visibility, the other is about remediation quality and decision speed.

Practical implication: treat inventory, policy, and search capabilities as the foundation for response, not as a substitute for exploit validation.

Threat narrative

Attacker objective: The objective is to exploit a dependency weakness that is actually reachable in production while defenders are distracted by noisy findings.

1. Entry occurs when a vulnerable package is introduced through a direct or transitive dependency in the software supply chain.
2. Escalation occurs when static analysis flags theoretical call paths that may never execute under production conditions, creating uncertainty about real exposure.
3. Impact occurs when teams spend remediation effort on low-value findings while truly exploitable dependency risks remain buried in the backlog.

NHI Mgmt Group analysis

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.

Runtime context is the missing control plane for dependency risk. Static graphs and vulnerability databases cannot fully capture feature flags, parameter values, or deployment-specific code paths. That gap explains why transitive reachability often overstates risk in nested libraries while missing the practical conditions that determine exploitation. In other words, the governance failure is assuming code presence equals exploitability. Practitioners need validation that reflects how the application actually runs, not how every theoretical path could behave.

Actionability should outrank completeness in supply chain tooling. Security teams gain more from direct dependency focus, repository search, SBOM coverage, and remediation traceability than from deeper but noisier transitive claims. This aligns with broader software supply chain governance, where the aim is to reduce decision friction and support accountable remediation. The named concept here is dependency actionability gap, the distance between a finding and a fixable security decision.

Identity and secrets governance still matter inside the same dependency problem. Supply chain risk is not just about package code. Vulnerable build systems, CI/CD tokens, API keys, and other non-human identities often sit close to the same workflows that process dependency alerts, which means poor secrets hygiene can turn an abstract finding into a real compromise path. NHI governance remains relevant wherever software delivery depends on long-lived credentials and third-party packages.

What this signals

Transitive reachability will remain useful only when teams treat it as one input into triage rather than as a stand-alone answer. The programme shift is toward evidence-based prioritisation, where runtime context, package inventory, and developer workflow data decide what gets fixed first. For broader dependency governance, pair this with the Ultimate Guide to NHIs , The NHI Market when evaluating tooling categories.

Dependency actionability gap: security leaders should expect more pressure to prove that vulnerability queues are reducing real risk, not just growing more precise. That means tighter alignment between SCA output, code owners, and release gates. Where secrets and service accounts are part of the same delivery pipeline, the control conversation should extend into NIST Cybersecurity Framework 2.0 protect and detect outcomes, not just package scanning.

For practitioners

• 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.
• Harden secrets around the software supply chain Reduce the chance that package risk becomes credential compromise by protecting build tokens, API keys, and service accounts used in CI/CD.

Key takeaways

• Transitive reachability analysis often increases certainty about package presence without increasing certainty about exploitability.
• The most useful supply chain controls are the ones that turn dependency data into concrete remediation decisions, not larger alert queues.
• Identity and secrets governance still matter because software supply chain risk frequently crosses into service accounts, build tokens, and other non-human identities.

Key terms

• Transitive dependency: A transitive dependency is a package that your application does not reference directly but still pulls in through another dependency. These nested packages can introduce vulnerabilities, licensing issues, or operational risk that is harder to see and harder to remediate than problems in direct dependencies.
• 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.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.

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.

👉 Semgrep's full post covers the false-positive problem, AST-based analysis, and the remediation trade-offs in transitive dependencies.

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 nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.