Software composition analysis tools now need runtime risk context

At a glance

What this is: This is a 2026 guide to software composition analysis tools, showing that modern SCA now centres on reachable risk, malware detection, and governance across open source dependencies.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly depend on software supply chain controls that govern secrets, build identity, and deployment trust, not just code scanning.

By the numbers:

• 77% of code in production applications today comes, oday comes from open source components.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Xygeni's full guide to software composition analysis tools for 2026

Context

Software composition analysis, or SCA, is the control layer that inventories third-party components and evaluates the risk they introduce into software delivery. In this article, the governance gap is not visibility alone, but the mismatch between dependency inventory and the real conditions under which a vulnerability, malicious package, or hidden transitive dependency can actually cause harm.

That matters to identity and access programmes because software supply chain compromise often travels through secrets, build pipelines, service accounts, and deployment credentials. Where open source packages, CI/CD systems, and runtime environments intersect with NHI governance, the question becomes whether access and trust are being granted to code paths that were never meant to have them.

This guide is typical of current SCA market positioning: it compares tools on reachability, exploitability, malware detection, and policy automation, while also revealing how vendors are trying to move buyers away from CVE-only thinking.

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 software dependency attacks still succeed when teams scan for CVEs?

A: CVE scanning only finds publicly disclosed weaknesses, but many supply chain attacks use malicious packages, typosquatting, or compromised updates that do not have a CVE. Teams need behavioural detection, provenance checks, and pipeline controls to catch threats that never appear in vulnerability feeds.

Q: What do security teams get wrong about SBOMs and open source governance?

A: Teams often treat SBOMs as the control itself rather than the inventory that supports control. An SBOM tells you what is present, but it does not tell you whether a package is malicious, whether a vulnerable function is actually used, or whether build identities are over-privileged.

Q: Why do build and release pipelines create identity risk in supply chain security?

A: Because they are governed by non-human identities with broad access to code, registries, and deployment systems. If those identities have standing credentials or overbroad scopes, patch automation can become a privileged attack path. The security issue is not just the software artefact, but the identity permissions that move that artefact through production.

Technical breakdown

Reachability analysis changes what counts as actionable SCA risk

Traditional SCA flags any dependency with a known vulnerability, but that creates noise when the vulnerable function is never invoked. Reachability analysis adds code-path context by checking whether the affected method or package can actually be reached at runtime. That is closer to how risk materialises in modern applications, especially when dependencies are deep, transitive, and reused across services. It also changes remediation prioritisation because teams can focus on exploitable exposure rather than theoretical presence.

Practical implication: classify findings by runtime reachability before routing them into development backlogs.

Malware in dependencies is a supply chain problem, not a CVE problem

A malicious package may have no published CVE, which means vulnerability-only scanning can miss the threat entirely. Behaviour-based malware detection looks for suspicious package activity, unwanted post-install behaviour, typosquatting patterns, and other signals that indicate a dependency is being used as a delivery vehicle. This matters because open source ecosystems reward speed and reuse, while attackers exploit trust in registries, maintainer names, and transitive imports. SCA therefore has to detect both known weaknesses and hostile intent embedded in the component itself.

Practical implication: add malware detection to dependency controls instead of relying only on vulnerability feeds.

SBOM and policy automation only help when they are tied to enforcement

An SBOM lists components, but it does not make a build safe on its own. The operational value comes when SBOM generation, license checks, and policy gates are wired into pull requests, CI/CD, and release approval. That way, teams can stop unapproved packages, enforce license rules, and document what changed before software ships. Without that enforcement layer, SBOMs become inventory artefacts rather than security controls, which is a common failure mode in mature-looking but weakly governed programs.

Practical implication: connect SBOM output to automated policy gates in the delivery pipeline.

Threat narrative

Attacker objective: The attacker wants trusted code paths to deliver malicious behaviour into build or runtime environments without triggering conventional vulnerability checks.

1. Entry occurs when a malicious or compromised package is introduced through a dependency manager, package registry, or transitive import path.
2. Escalation follows when the package executes during build or runtime and gains access to secrets, tokens, or trusted pipeline context.
3. Impact occurs when the dependency is used to exfiltrate data, compromise the software supply chain, or propagate malicious code downstream.

NHI Mgmt Group analysis

Runtime-dependent risk is now the decisive SCA concept. SCA has matured from inventorying vulnerable packages to judging whether a flaw is actually reachable inside the application path. That shift matters because unreachable findings consume attention without reducing real exposure. Reachability-based prioritisation is now a governance issue, not just a scanning feature, because teams need to decide which dependency risks deserve build-breaking treatment and which do not.

Malware detection closes the blind spot that CVE-centric tooling leaves open. Most supply chain attacks do not depend on published vulnerability data, and that means conventional SCA can miss hostile packages entirely. The security lesson is simple: a clean CVE report does not equal a clean dependency. Practitioners should treat package behaviour, maintainer integrity, and registry trust as first-class control inputs, especially where build pipelines already contain secrets and service credentials.

Software supply chain governance now intersects directly with NHI security. Build systems, deployment tooling, and developer workflows are identity-rich environments, and compromise often becomes useful only when the attacker reaches tokens, API keys, or service accounts. That is why the boundary between SCA and NHI governance is collapsing. The right conclusion is not just better dependency scanning, but tighter control over the non-human identities that sign, fetch, build, and deploy software.

Named concept: dependency reachability debt. This is the gap between how many vulnerable packages are present and how many can actually be exploited in context. When organisations cannot separate exposed risk from theoretical risk, they accumulate remediation debt that weakens both developer trust and security response. Practitioners should treat this as a prioritisation failure with direct governance consequences.

Tool consolidation is pushing SCA into broader application security platforms. The market signal here is that buyers increasingly expect SCA, secrets detection, malware analysis, and CI/CD integration to work together. That trend validates a broader control model, but it also creates a new evaluation problem: teams must determine whether breadth is masking weak depth in the controls that matter most to their supply chain risk.

What this signals

Dependency reachability is becoming a practical triage signal for security programmes. Teams that cannot distinguish live execution paths from dormant package presence will keep over-investing in low-value remediation. That is why SCA, secrets control, and build identity governance now need to be handled together, not as separate operational queues.

The next stage of software supply chain governance is likely to favour tools that correlate package behaviour, provenance, and pipeline identity in one workflow. For practitioners, that means evaluating whether current controls can stop malicious dependencies before they gain access to tokens, service accounts, or release systems rather than only after a vulnerability has been logged.

For practitioners

• Prioritise reachable vulnerabilities first Gate remediation by runtime reachability and exploitability so that developers fix only dependency issues that can actually be executed in the application path.
• Block malicious packages before merge Add behaviour-based malware detection to dependency review so that typosquatting, backdoored packages, and suspicious install-time activity are caught before they enter CI/CD.
• Tie SBOMs to enforcement rules Use SBOM generation to drive policy checks for license, provenance, and forbidden components instead of treating the SBOM as a reporting artifact only.
• Treat pipeline identities as part of supply chain security Review the service accounts, tokens, and credentials used by build and release systems, because dependency compromise becomes operational only when those non-human identities are accessible.

Key takeaways

• SCA is shifting from dependency inventory toward runtime-risk judgement, which reduces noise and improves remediation quality.
• Malicious packages expose a control gap that CVE-only scanning cannot close, especially in CI/CD environments that hold secrets and privileged identities.
• Practitioners should connect SBOMs, policy enforcement, and pipeline identity governance so supply chain controls actually block risky software from shipping.

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.
• Dependency Malware: Dependency malware is malicious code hidden inside an open source package or library that is delivered through normal software distribution channels. It can bypass CVE-only thinking because the threat comes from hostile behaviour, not a published vulnerability record.

What's in the full article

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

• Per-tool capability comparison across exploitability, malware detection, and license governance for teams shortlisting SCA platforms.
• Pricing and packaging details that matter when procurement needs to compare platform breadth against implementation cost.
• Vendor-specific feature notes on reachability, auto-fix, SBOM generation, and CI/CD integrations for deployment planning.
• The article's own assessment of where each platform fits in developer workflows versus enterprise governance programmes.

👉 Xygeni's full article includes the feature-by-feature comparison, pricing notes, and implementation trade-offs.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity across modern enterprise environments. It helps practitioners connect identity control to the broader security programmes that software delivery depends on.