SCA tools in 2025: why dependency risk now spans runtime

At a glance

What this is: This is a review of top SCA tools for 2025, with the main finding that dependency risk now has to be assessed across code, pipelines, and runtime, not only in manifests.

Why it matters: For IAM and security practitioners, that matters because open-source components increasingly behave like managed access surfaces, with secrets, build permissions, and deployment context shaping real exploitability.

By the numbers:

• Open source now makes up 70 to 90% of the code in modern software.
• Sonatype’s 2023 report found 245,032 malicious packages, and this number tripled in just one year.

👉 Read OXSecurity's full review of the top 10 SCA tools for 2025

Context

Software composition analysis is meant to answer a simple question: what third-party code is in the application, and what risk does it bring? In practice, that question has become harder because dependencies now move through build systems, CI/CD pipelines, artifact stores, and cloud runtime, where exposure can emerge long after a package was first declared.

That shift matters for identity and access governance as well as AppSec. Open-source packages, build agents, and deployment pipelines all rely on secrets, permissions, and trust relationships, so SCA findings increasingly need to be read alongside NHI governance, access scope, and runtime exposure rather than treated as isolated component issues.

Key questions

Q: How should security teams prioritise SCA findings in modern delivery pipelines?

A: Prioritise SCA findings by exploitability, not by raw count. Start with dependencies that are reachable in production, attached to internet-facing services, or introduced by a privileged build path. Then separate security defects from license conflicts so the right owners can act without slowing every release for every issue.

Q: Why do transitive dependencies create more risk than teams expect?

A: Transitive dependencies are often invisible to the developer who triggered them, but they still become part of the shipped application. That means a package several layers deep can introduce a known CVE, a malicious update path, or a compliance issue without any direct code change by the team.

Q: What do security teams get wrong about Software Composition Analysis?

A: The common mistake is treating SCA as a one-time scan of source code. In practice, risk changes as code moves through builds, artifacts, and runtime. Teams that ignore pipeline context and deployment state end up with noisy reports that do not tell them which exposure is actually exploitable.

Q: How should organisations decide whether to block a release for an SCA finding?

A: Block the release when the vulnerable component is reachable, internet-exposed, or tied to a high-value service where exploitation would materially change business risk. If the issue is not reachable, track it with a deadline and owner instead of turning every alert into an emergency.

Technical breakdown

Why SCA now has to extend beyond manifest scanning

Traditional SCA starts with declared dependencies in files such as package-lock.json, pom.xml, or requirements.txt. That still matters, but it only shows intent, not actual exposure. Modern applications pull in transitive packages, container layers, and build outputs that can change between merge and deployment. Effective SCA therefore maps component identity, version, and vulnerability status to the places the software actually runs. That is where exploitability becomes real, because a vulnerable library inside an unused test path is not the same as one reachable from an internet-facing service.

Practical implication: prioritise tools that connect dependency findings to running services and deployment paths, not just repository manifests.

How pipeline context changes remediation priority

Pipeline context tells you how a vulnerable component entered the system, which build introduced it, and whether the issue was promoted by a release gate or merged unnoticed. Without that context, teams often fix the loudest CVEs first instead of the ones most likely to be reachable in production. This is especially important when dependencies are packaged once and reused across multiple services, because the same library can create different risk levels depending on where it is deployed and what network or privilege boundary surrounds it.

Practical implication: link SCA findings to CI/CD metadata so remediation can target the build that introduced the exposure.

Why runtime and exploitability data reduce SCA noise

Runtime data answers whether a dependency is actually reachable, internet-exposed, or tied to a service with meaningful business impact. That moves SCA from a static inventory exercise to a risk-ranking system. It also helps distinguish policy noise from actionable exposure, which matters when teams are already flooded by transitive findings and licensing alerts. In that sense, SCA becomes most useful when it is paired with cloud runtime telemetry and application context, not when it sits as a disconnected pre-build scanner.

Practical implication: use reachability and runtime exposure to rank SCA alerts before opening tickets or blocking releases.

Threat narrative

Attacker objective: The attacker wants to turn trusted software supply chains into a scalable path to code execution, data access, or broad downstream compromise.

1. Entry occurs when attackers target trusted open-source dependencies, malicious packages, or exposed build and pipeline artefacts rather than the application code itself.
2. Escalation follows when vulnerable or tampered dependencies are promoted through CI/CD and become reachable inside production services with broader runtime access.
3. Impact appears when the compromised component enables remote code execution, data theft, or downstream compromise across multiple deployed services.

NHI Mgmt Group analysis

SCA has moved from component discovery to exposure governance. The article shows why scanning for known CVEs is no longer enough when the real question is whether a dependency is reachable in production, tied to a privileged pipeline, or exposed through runtime paths. That changes SCA from a software inventory task into a governance control for exploitability. Practitioners should treat this as an exposure-ranking discipline, not a checklist of package hygiene.

Transitive dependency risk is a secret and identity problem as much as a code problem. Open-source supply chains depend on build secrets, CI credentials, artifact permissions, and service identities to move code into production. When those identities are too broad, SCA findings become only one part of a wider trust failure. Teams need to align dependency scanning with NHI governance so pipeline credentials, deployment tokens, and service accounts do not extend the blast radius of a vulnerable package.

Reachability context creates a more defensible remediation model. The article’s emphasis on Code Projection reflects a broader market shift toward controls that connect static findings to runtime evidence. That matters because most organisations cannot remediate every CVE at once, and flat alerting creates fatigue. A named concept here is dependency exposure drift: the gap between where a package is declared and where it is actually exploitable. Security teams should use that concept to focus on the components that have crossed from code risk into business risk.

Tool selection is increasingly about workflow integration, not scan coverage. The article highlights a familiar failure mode in AppSec programmes: tools that detect many issues but do not fit the developer and release workflow that decides whether those issues matter. Good governance depends on feedback timing, build context, and reporting quality as much as scanner depth. Practitioners should evaluate SCA as part of the delivery system, not as a standalone control.

Software supply chain security now requires cross-domain ownership. SCA findings often surface in AppSec, but the controls that determine exploitability live across IAM, PAM, cloud runtime, and DevSecOps. That means security leaders need shared ownership for dependency risk, build identity, and release authorization. Teams that keep SCA isolated from identity and runtime governance will continue to see the same vulnerabilities reappear in different forms.

What this signals

Dependency exposure drift: the practical issue is no longer whether a package has a CVE, but whether that package has crossed from code inventory into reachable production exposure. As SCA tools absorb runtime and pipeline context, teams will increasingly need to align application security with release governance and identity controls around build systems.

For programmes that already track service accounts and deployment tokens, this is a useful place to connect AppSec and NHI governance. A dependency may be the entry point, but the blast radius is usually shaped by who can promote, sign, publish, or deploy it. That is why controls from NIST Cybersecurity Framework 2.0 and dependency-to-runtime mapping deserve to sit in the same conversation.

The next maturity step is less about finding more issues and more about proving which issues matter in a live environment. Teams that can explain exposure, reachability, and business impact will be able to defend remediation decisions to engineering leadership without defaulting to alert volume as the only signal.

For practitioners

• Prioritise reachable dependencies first Rank SCA findings by whether the library is actually reachable in production, not just whether it appears in a manifest or lockfile. Use runtime exposure, service mapping, and internet-facing status to decide what gets fixed before the next release.
• Bind findings to build provenance Track which commit, pipeline, and artifact introduced each vulnerable component so remediation targets the correct release path. That reduces duplicate work and prevents the same dependency from re-entering through another build branch.
• Review pipeline identities and secrets together Audit the credentials, tokens, and service accounts that allow dependency updates, artifact publication, and deployment promotion. Over-privileged pipeline identities can turn a routine package issue into a broader supply chain compromise.
• Separate license risk from exploit risk Treat legal license conflicts and security vulnerabilities as different triage streams. They may appear in the same tool, but they require different owners, different service-level expectations, and different escalation paths.
• Set alert thresholds by business criticality Use application criticality, internet exposure, and downstream reachability to decide when an SCA alert blocks a release and when it becomes a tracked remediation item. This keeps developer velocity while still protecting the most exposed services.

Key takeaways

• SCA has become a runtime governance problem, not just a repository scan, because dependencies now move through builds and deployments before risk is visible.
• The strongest prioritisation signal is exposure context, especially whether a vulnerable component is reachable, internet-facing, or tied to a privileged pipeline.
• Security leaders should connect SCA with pipeline identity, secret handling, and release governance or the same dependency risks will keep reappearing downstream.

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.
• 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.
• 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

OXSecurity's full article covers the operational detail this post intentionally leaves for the source:

• Side-by-side feature comparison of the top 10 SCA tools across CI/CD, IDE, and runtime workflows
• Tool-specific notes on SBOM generation, license enforcement, and remediation automation
• Implementation observations on how each platform handles transitive dependencies and alert volume
• Practical fit guidance for teams choosing between developer-first and enterprise-grade SCA approaches

👉 The full OXSecurity article covers tool-by-tool comparisons, pipeline fit, and remediation details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management in the contexts that underpin secure delivery pipelines. It is designed for practitioners who need to connect identity controls to broader security programmes with confidence.