TL;DR: Software composition analysis has moved beyond CVE lists toward reachability, exploitability, malware detection, and SBOM support as open source dependency risk becomes a supply chain problem, according to Xygeni. The governance question is no longer whether to scan dependencies, but whether teams can separate theoretical exposure from runtime risk fast enough to protect delivery.
At a glance
What this is: This guide argues that modern software composition analysis must evaluate runtime risk, not just dependency presence, because reachable flaws and malicious packages drive the real supply chain exposure.
Why it matters: For IAM, NHI, and DevSecOps teams, this matters because dependency risk increasingly intersects with secrets, build pipelines, and release governance, where static inventories alone do not show which exposures can be exploited.
Context
Software composition analysis is the discipline of finding and governing open source components, third-party packages, and the risk they bring into software delivery. The article’s core point is that dependency presence is not the same as operational risk, because vulnerable code may never run while malicious code may still execute at build or runtime.
That distinction matters for identity and access governance because supply chain tooling increasingly touches build credentials, pipeline permissions, and release integrity. In practice, teams need to understand not only what is in the software bill of materials, but also whether any component can reach privileged paths during execution.
Key questions
Q: Why is reachability analysis more useful than CVE-only scanning for SCA?
A: Reachability analysis tells you whether a vulnerable function can actually be called in the running application, which is far more actionable than a raw dependency list. CVE-only scanning overstates risk when the affected code is dead, but reachability helps teams focus remediation on flaws that can be exploited in practice.
Q: What breaks when software composition analysis stops at the SBOM?
A: An SBOM gives visibility into what components are present, but it does not tell you which dependencies are exploitable, trusted, or malicious. If teams stop at the inventory layer, they can miss runtime exposure and package tampering, which are often the conditions that turn open source into an attack path.
Q: How should teams govern supply chain risk when packages may be malicious?
A: Treat package intake as a trust decision, not just a vulnerability check. Teams should combine provenance, malware detection, reachability, and policy controls so that a dependency is only approved when it is both known and operationally safe in the target environment.
Q: What should DevSecOps teams do when SCA findings are tied to build credentials?
A: They should review which tokens, service accounts, and pipeline roles can install, publish, or promote dependencies, then reduce that access to the minimum needed. When build credentials are broad, a single package compromise can spread quickly through release systems and artifact stores.
Technical breakdown
Why reachability changes SCA triage
Reachability analysis asks whether a vulnerable function is actually invoked in the running application. A package can carry a CVE without creating practical exposure if the affected code path is never executed. That is why modern SCA tools increasingly enrich dependency data with call graph context, language-level usage, and runtime signals. The result is not fewer findings by chance, but a narrower set of findings that map to exploitable conditions rather than theoretical presence. For DevSecOps teams, this is the difference between policy noise and evidence-based prioritisation.
Practical implication: Use reachability data to prioritise the dependencies that can actually be triggered in production, not every flagged library.
How exploitability scoring and EPSS reshape dependency risk
Exploitability scoring combines vulnerability severity with evidence that exploitation is realistic, often using external signals such as EPSS and contextual policy rules. This matters because CVSS alone says how bad a flaw could be, not whether it is likely to be used against your environment. In SCA, exploitability scoring becomes most useful when it is paired with runtime context, package criticality, and whether a vulnerable path is public-facing or internally isolated. That makes prioritisation closer to operational risk management than static hygiene.
Practical implication: Tie vulnerability prioritisation to exploitability and exposure context so engineering effort follows realistic attack paths.
Why malware detection is a different control from CVE scanning
CVE scanning answers whether a package is known to contain a published vulnerability. Malware detection answers whether the dependency itself is malicious, even if no CVE exists. That distinction is important because supply chain attacks often use typosquatting, dependency confusion, or post-publish package tampering, none of which depend on a traditional vulnerability record. Behaviour-based or reputation-based scanning therefore fills a gap that manifest-only tools cannot close. For software teams, malware detection is a separate layer of trust assurance, not just another vulnerability filter.
Practical implication: Add malware and package-trust checks to dependency controls so malicious components are blocked before they enter the delivery pipeline.
Threat narrative
Attacker objective: The attacker seeks to turn trusted software delivery into a compromise path by getting malicious or exploitable code executed inside the application supply chain.
- Entry occurs when a malicious or vulnerable open source package enters the build or dependency chain through normal development workflows.
- Credential or package trust abuse follows when the dependency is accepted as legitimate and its code is pulled into CI/CD or runtime paths.
- Impact occurs when the risky component becomes executable in production or exposes a path for supply chain compromise, data theft, or malicious behaviour.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
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
Runtime context is now the dividing line between useful SCA and noisy compliance theatre. The article reflects a broader market shift from dependency enumeration to exposure judgement. Static manifest scans can tell you what is present, but not whether a vulnerable library is reachable in the running code path. Practitioners should treat reachability as the control that separates theoretical risk from actionable risk.
Supply chain security has become a trust problem, not just a vulnerability problem. The article’s emphasis on malicious packages shows why open source risk cannot be reduced to CVE feeds alone. Package provenance, behavioral signals, and pipeline trust all matter because a dependency can be harmful even when it is not technically vulnerable. Teams should govern package intake as a trust decision, not only a patching decision.
Software composition analysis now sits closer to identity and pipeline governance than many buyers admit. Build systems, package registries, and CI/CD runners rely on credentials, tokens, and permissions that can amplify dependency risk. That creates an identity bridge between application security and NHI governance, especially where automation has standing access to registries or release systems. Practitioners should map SCA findings to the credentials that make software delivery possible.
SBOMs are necessary, but they do not answer the operational question on their own. An inventory of components supports transparency, yet it does not reveal exploitability, runtime reachability, or malicious intent. The useful programme is one that combines inventory, trust, and execution context into a single decision model. Teams should use SBOMs as the baseline and runtime-risk context as the decision layer.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: NHI Lifecycle Management Guide
What this signals
Runtime-risk context is becoming the new SCA baseline: teams that still prioritise by manifest presence alone will keep drowning in findings that never become exploitable. The better control question is whether a dependency can be reached, executed, or substituted inside the delivery pipeline.
Software supply chain governance now overlaps with identity governance because build systems depend on secrets, tokens, and scoped automation accounts. That means SCA findings should be reviewed alongside the credentials that allow packages to move from source control to production.
The practical programme shift is to treat inventory, exploitability, and trust as one decision path, not three separate reviews. That is how security teams reduce noise without losing sight of runtime risk.
For practitioners
- Prioritise reachable dependencies first Rank open source findings by whether the vulnerable code path is actually executed in production, then treat unreached CVEs as lower operational priority until context changes.
- Separate malware checks from CVE scanning Add package trust and behaviour-based malware detection to your SCA pipeline so malicious dependencies are screened even when no CVE exists.
- Map dependency findings to delivery credentials Review which build and registry credentials can install, publish, or promote packages, then narrow those permissions to reduce supply chain blast radius.
- Use SBOMs as an input, not the decision Treat the SBOM as the inventory layer and pair it with runtime, exploitability, and policy data before approving remediation or release decisions.
Key takeaways
- Modern SCA now has to judge runtime exposure, not just list the packages present in a codebase.
- Malicious packages and exploitable dependencies are different problems, so CVE scanning alone is no longer enough.
- The strongest control pattern combines reachability, malware detection, and credential governance around the delivery pipeline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Dependency and build workflows rely on secrets that can be exposed through compromised packages or pipelines. |
| Recommendation — Scan dependency and pipeline secrets under NHI-02 and revoke any exposed credentials immediately. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Open source supply chain compromise often uses stolen tokens to reach code and steal secrets. |
| Recommendation — Map package compromise indicators to TA0006 and TA0010 to hunt for credential theft and secret exfiltration. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest | SBOMs, package artifacts, and dependency records are data assets that need controlled handling. |
| Recommendation — Protect dependency inventories and artifact stores with PR.DS-01 controls to reduce tampering and leakage. | ||
| CIS Controls v8 | CIS-5 — Account Management | Build and registry accounts are part of the access surface that turns package risk into delivery risk. |
| Recommendation — Tighten account lifecycle controls for build and registry identities so package compromise has less reach. | ||
| SLSA | L3 — Build Integrity | Runtime-risk-aware SCA sits inside a broader requirement for trustworthy builds and artifact provenance. |
| Recommendation — Apply SLSA build integrity practices so dependency risk cannot be hidden by an untrusted pipeline. | ||
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.
- Exploitability Benchmark: An exploitability benchmark tests whether a model can progress from a weak signal to a working proof of concept against planted or known vulnerabilities. It is closer to real offensive validation than generic model scoring because it measures practical attacker outcomes.
- SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced 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. It is designed for practitioners who need to connect credential governance and access control to the wider security programme.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org