SCA tools in 2025: why dependency risk now spans runtime

At a glance

What this is: This is an analysis of why Software Composition Analysis in 2025 has to cover build, deployment, and runtime exposure, not just manifest-level CVE scanning.

Why it matters: It matters because IAM, AppSec, and cloud teams need to govern where vulnerable dependencies actually execute, which services can reach them, and how quickly exploitable packages move into production.

Context

Software Composition Analysis is the control discipline for discovering and assessing third-party and open-source dependencies in software. The governance gap is that many teams still treat SCA as a pre-merge hygiene check, even though the risk often appears later when packages are built, shipped, and exposed in live environments. For identity and access teams, that matters because the dependency itself is only part of the problem; the runtime and pipeline context determines whether a vulnerable component is actually reachable.

The article’s core argument is that dependency risk has become a lifecycle problem, not a source-code-only problem. That shifts SCA from static inventory toward operational governance across CI/CD, SBOM tracking, and exploitability analysis. The practical challenge is filtering noise from real exposure, which is now a shared concern for AppSec, platform engineering, and cloud security programmes.

Key questions

Q: What breaks when SCA stops at pre-merge scanning?

A: Teams lose visibility into whether a dependency is actually deployed, reachable, or exploitable in production. That means the scan may be technically accurate but operationally incomplete, because build, runtime, and network context determine whether the vulnerability matters. In practice, pre-merge only SCA creates noise without enough signal to support prioritisation.

Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?

A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews. If defenders only track direct components, they can miss the code attackers are most likely to exploit. A dependency-aware inventory reduces that blind spot and gives teams a realistic view of what is actually present in production.

Q: How should teams decide which security findings to fix first?

A: Prioritise findings that are both reachable and tied to active code paths. A raw alert list is not enough because many issues will never be exploitable in practice. The best triage model combines severity with code-path evidence, so engineering time goes to defects that can actually affect production risk.

Q: How should teams govern dependency risk across CI/CD and runtime?

A: Treat dependency governance as a lifecycle control, not a single scan. Use SBOMs, pipeline provenance, and runtime mapping to connect a vulnerable package to the artifact and service that actually shipped. That gives security and engineering teams a shared view of where risk entered, where it runs, and how far it can spread.

Technical breakdown

Why manifest-level SCA misses runtime dependency risk

Traditional SCA inspects package manifests and lockfiles to identify known vulnerable dependencies before release. That works for obvious issues, but it misses how software behaves once it is built, deployed, and connected to real infrastructure. A dependency can be present in source yet never executed, or buried deep enough in the tree that it only matters in certain runtime paths. Modern SCA therefore needs reachability, deployment location, and environment context to decide whether a CVE is operationally relevant. Without that, teams get broad vulnerability lists but little guidance on which findings can actually be exploited.

Practical implication: Prioritise SCA outputs that include runtime and reachability context rather than treating every manifest hit as an actionable risk.

How pipeline and build context change dependency governance

Build systems turn code-level dependency risk into supply chain risk because they determine what is packaged, signed, and promoted. A vulnerable library that passes through CI/CD can become a production issue even if the source repository is cleaned up later. This is why SBOMs, pipeline metadata, and artifact tracking matter: they preserve the chain from commit to deployed component. In practice, SCA becomes more useful when it can answer which build introduced the dependency, which artifact shipped it, and whether the exposed service is actually using it. That moves the control from scanning to governance of software lineage.

Practical implication: Tie dependency findings to build and artifact provenance so you can isolate where vulnerable packages entered the delivery chain.

Why exploitability context matters more than raw CVE counts

A raw CVE count is not a risk model. Two packages with the same vulnerability can represent very different levels of exposure depending on whether the vulnerable function is reachable, whether the service is internet-facing, and whether the component sits in a high-privilege path. That is why contextual correlation is increasingly important in SCA. Teams need to know whether a flaw is only theoretical, whether it is known exploited, and whether it sits in code that can be triggered in the current deployment. This is where SCA starts to overlap with broader AppSec and cloud governance, because exploitability depends on environment, not just software composition.

Practical implication: Use exploitability and exposure signals to separate operational risk from inventory noise before assigning remediation work.

Threat narrative

Attacker objective: The attacker objective is to turn trusted dependency use into exploitable application access in production.

1. Entry occurs when a vulnerable open-source dependency is pulled into the build through normal package management or transitive inclusion.
2. Credential or code access is not the main issue here, but the package becomes part of a trusted pipeline artifact that can later be executed in production.
3. Escalation happens when the vulnerable component is deployed into a reachable service path or privileged runtime environment where its flaw can be triggered.
4. Impact is achieved when attackers exploit the dependency to gain code execution, data exposure, or broader compromise in a live application.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Dependency governance is now a runtime problem, not just a pre-commit problem. SCA that stops at the manifest misses the point of modern delivery pipelines, where packages are promoted, containerised, and executed long after the original scan. The right governance question is no longer only what is in the repository, but where the component actually runs and whether the vulnerable path is reachable. Practitioners should treat dependency governance as part of runtime exposure management.

Blast-radius reduction is the real SCA objective. The article’s emphasis on context, deploy location, and exploitability reflects a broader shift away from alert volume and toward risk containment. In practice, that means vulnerable packages matter most when they sit inside exposed services, privileged build paths, or widely reused artifacts. Teams should optimise for fewer reachable exposures, not merely fewer findings.

Reachability context is the named concept that separates inventory from risk. A dependency list tells you what exists, but reachability tells you what can actually hurt you. That distinction becomes critical when transitive packages outnumber first-party code and when runtime behaviour determines whether a CVE is actionable. Practitioners should make reachability a primary triage signal in dependency governance.

SCA and application governance are converging. The article shows why software composition analysis now overlaps with pipeline security, artifact provenance, and cloud runtime control. That convergence matters because a dependency vulnerability is only meaningful when paired with the systems that build, ship, and execute it. Security teams should govern dependencies as part of the full software lifecycle, not as a standalone scan result.

Noise suppression is a governance control, not a convenience feature. The article’s discussion of raw alerts versus narrowed findings reflects a real programme issue: if teams cannot distinguish exploitable from non-exploitable dependencies, remediation becomes unbounded. The control objective is not perfect detection volume, but defensible prioritisation. Practitioners should demand tooling that maps findings to business and runtime relevance.

What this signals

Reachability is becoming the deciding control in dependency governance. When a package is present but never executed, it should not carry the same remediation priority as a vulnerable library that sits on an internet-facing code path. That shift forces SCA to integrate with runtime telemetry, deployment inventory, and service topology rather than remaining a repository-only check.

The governance gap is not discovery, it is disposition. Most teams can find vulnerable components; fewer can explain which ones are shipped, reachable, and worth fixing first. That is why dependency risk management increasingly belongs alongside pipeline security and application runtime control, not just in AppSec scanning workflows.

For practitioners

• Map dependency findings to runtime exposure Prioritise components only when the vulnerable package is actually deployed in an exposed service or privileged execution path.
• Correlate SCA with pipeline provenance Record which build, artifact, and pipeline change introduced each dependency so remediation can target the right delivery stage.
• Triage transitive dependencies separately Treat deep transitive libraries as a distinct risk class because they often carry the most hidden exposure and the least developer visibility.
• Use exploitability before severity Compare CVE severity with reachability, internet exposure, and service privilege before deciding what enters the fix queue.
• Maintain SBOM continuity across release stages Keep SBOM data current from code to deployment so you can tell which shipped artifact still contains the vulnerable component.

Key takeaways

• Modern SCA now has to answer where a dependency runs, not only whether it exists in source control.
• The most useful finding is the one that can be tied to reachability, deployment, and exploitability.
• Dependency governance becomes actionable when teams connect scans to pipeline provenance and runtime exposure.

Key terms

• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
• 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.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.

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.