TL;DR: Open source code now sits in nearly every production application, but the security stack around it remains fragmented, with some tools focused on CVEs, others on malware behaviour, and only a few on runtime reachability and safe remediation, according to Xygeni. The decisive issue is not tool count but whether teams can separate noise from exploitable supply-chain risk.
At a glance
What this is: This guide compares eight open source security tools and finds that most still cover only part of the supply-chain risk problem, leaving gaps in malware detection, reachability, and safe remediation.
Why it matters: IAM, PAM, and software security teams need to understand these gaps because open source dependencies are increasingly part of the trusted runtime and build chain, where exposed credentials and poisoned packages can become identity and delivery risks.
By the numbers:
- Open source code appears in 97 percent of modern applications, according to GitHub’s Octoverse Report cited by Xygeni.
- The Sonatype State of the Software Supply Chain report documented a 1,300 percent rise in malicious packages published to public registries in recent years, according to Xygeni.
- The Synopsys OSSRA 2024 report found that 84 percent of analyzed codebases contained at least one known vulnerability, according to Xygeni.
Context
Open source security now sits at the intersection of software delivery, supply-chain risk, and identity governance because modern build systems rely on third-party components, package registries, CI/CD automation, and machine credentials. The practical problem is not whether organisations use open source, but whether their controls can distinguish harmless dependency noise from packages and workflows that can actually be exploited.
The article frames a familiar governance gap: many tools specialise in one layer, such as CVE matching, license control, or container scanning, while attackers increasingly target behaviour, maintainer trust, and build-time privilege. That makes the issue relevant to NHI and agentic AI teams as well, because the same pipelines that consume open source components also consume secrets, tokens, and delegated access.
Key questions
Q: What fails when open source security tools rely only on CVE scanning?
A: CVE-only tooling misses malicious packages, post-install abuse, and vulnerable code that is never executed. It also creates noisy queues that bury the dependencies that actually matter. Teams need behavioural detection and reachability evidence so the control is based on exploitability, not just catalogued weakness.
Q: Why do open-source components and CI/CD pipelines increase software supply chain risk?
A: Open-source components and CI/CD pipelines expand the attack surface because they introduce third-party code, automation, and many trusted handoffs. If a malicious module, tampered dependency, or compromised pipeline slips through, attackers can inject code, steal secrets, or alter builds before release. The risk rises when teams lack visibility, approval controls, and continuous scanning.
Q: What do security teams get wrong about dependency remediation prioritisation?
A: They often rank findings by severity alone, which does not reflect whether a vulnerability is reachable, exposed to the internet, or likely to be exploited. Better prioritisation combines reachability, exploit likelihood, and business context so remediation effort matches real risk.
Q: What is the difference between behavioural package analysis and reachability analysis?
A: Behavioural analysis looks for suspicious package actions such as network access, file writes, or environment-variable reads during installation. Reachability analysis asks whether a known vulnerable function is actually called in the deployed application. One detects malicious intent, the other filters whether a weakness is operationally relevant.
Technical breakdown
Why CVE-only scanning misses supply-chain abuse
CVE matching tells you whether a package has a known vulnerability, but it does not tell you whether the package is malicious, whether the vulnerable code is reachable, or whether the finding matters in your environment. Open source risk is therefore a compound problem: disclosure, exploitability, runtime use, and build context all need to line up before a finding becomes actionable. Behavioural package analysis closes one gap by examining what code does at install time, while reachability analysis closes another by checking whether vulnerable functions are actually invoked. Practical implication: separate known-vulnerability triage from behavioural threat detection and runtime reachability before routing remediation.
Practical implication: separate known-vulnerability triage from behavioural threat detection and runtime reachability before routing remediation.
How build pipelines turn dependencies into identity-bearing trust chains
Modern CI/CD systems do more than compile code. They fetch packages, sign artifacts, call APIs, and use secrets or service accounts to move from source to deployment. That means a dependency compromise can become a trust-chain compromise if a malicious package executes during install or a compromised maintainer token influences the build. In NHI terms, the pipeline itself becomes a consumer of non-human credentials and delegated privileges, so dependency security cannot be isolated from machine identity governance. Practical implication: treat package intake, pipeline credentials, and artifact promotion as one control plane instead of separate teams and tools.
Practical implication: treat package intake, pipeline credentials, and artifact promotion as one control plane instead of separate teams and tools.
Why remediation safety matters as much as detection
Finding a risky dependency is only half the job. Teams also need to know whether the proposed fix will break the build, introduce a new issue, or leave the original exposure untouched. That is why safe remediation workflows matter: they reduce the chance that security teams create production instability while trying to remove supply-chain risk. Prioritisation based on EPSS, internet exposure, business impact, and reachability is more useful than severity alone because it aligns the fix queue with actual exploitation likelihood. Practical implication: require remediation proposals to show breakage risk and replacement impact, not just vulnerability counts.
Practical implication: require remediation proposals to show breakage risk and replacement impact, not just vulnerability counts.
Threat narrative
Attacker objective: The attacker aims to turn trusted package ingestion into a route for secret theft, build compromise, or malicious code propagation.
- Entry occurs when a malicious or compromised open source package enters the build path through a registry, dependency update, or typosquatted name.
- Credential access or execution follows when the package runs install-time scripts, reads environment variables, or touches build credentials and tokens.
- Impact lands when stolen secrets, poisoned dependencies, or altered artifacts reach downstream systems and create production compromise or supply-chain spread.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
Supply-chain security has moved beyond vulnerability scoring. CVE-only workflows cannot distinguish a dangerous package from a merely imperfect one, and that gap is now central to software risk management. Behavioural analysis and reachability analysis answer different questions, so teams that collapse them into one scanner are still blind to the most relevant threat classes. Practitioners should govern open source as a trust problem, not just a defect problem.
Runtime reachability is the new triage boundary. Most organisations do not need more alerts, they need fewer false positives and better evidence that a finding can actually be reached in production. That shifts the security question from whether a component has flaws to whether those flaws can be exercised in the deployed application. Practitioners should use runtime exposure and call-graph evidence to decide what enters the fix queue.
Package ingestion is also machine-identity governance. Build systems authenticate to registries, invoke automation through service accounts, and carry secrets through pipelines, so dependency security is inseparable from NHI control. If a malicious package can read environment variables or trigger post-install behaviour, the issue is not only software hygiene but the privilege granted to the pipeline. Practitioners should align dependency controls with NHI lifecycle and pipeline privilege review.
Open source security is becoming a policy-enforcement problem, not just a scanning problem. The article’s tool comparison shows a widening gap between tools that report issues and tools that block unsafe promotion, support safe fixes, and fit the development workflow. That matters because supply-chain risk is now operationally expensive only when policy can stop it before release. Practitioners should favour controls that turn findings into gated decisions.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Package security is now a governance issue for build systems, not just a developer hygiene issue. When software delivery depends on third-party packages, the question becomes who can introduce code, who can approve it, and which controls can stop unsafe promotion before release. That puts supply-chain checks directly alongside secrets handling and pipeline identity controls.
Behavioural detection changes the threat model. If a package can be flagged because it tries to read environment variables or reach out to the network at install time, then the control objective shifts from catalogue matching to observed intent. Practitioners should expect more value from tools that inspect behaviour than from scanners that only read metadata.
The relevant programme signal is simple: dependency security and NHI governance are converging in the same delivery path, so teams that separate package review from pipeline credential control will keep missing the real failure mode.
For practitioners
- Prioritise behavioural package detection Use behavioural package analysis for npm, PyPI, and Maven dependencies that may be malicious even when no CVE exists, and quarantine suspicious packages before merge or release.
- Add reachability-based triage Filter dependency findings by whether vulnerable code is actually executed at runtime, so remediation focuses on exploitable paths rather than every listed CVE.
- Review pipeline credentials alongside dependency intake Treat registry access tokens, CI service accounts, and build secrets as part of the same supply-chain control boundary as third-party packages.
- Require safe-remediation evidence Before approving an automated fix, check the breakage risk, compatibility impact, and replacement path so the patch does not create a new operational issue.
- Enforce policy at build time Block promotion of packages or artifacts that fail supply-chain checks, rather than relying on post-release cleanup after the dependency is already deployed.
Key takeaways
- Open source risk is no longer defined only by whether a component has a published CVE, because malicious packages and runtime reachability now matter just as much.
- The article’s comparison shows a clear split between tools that scan dependencies and tools that also inspect behaviour, prioritise exploitability, and support safer remediation.
- Practitioners should align supply-chain controls with pipeline identity, package intake, and build-time policy enforcement rather than relying on post-release cleanup.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Package and pipeline secrets are exposed in the attack paths discussed here. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party package and registry trust is central to this supply-chain risk. | |
| Recommendation — Scan build logs, package flows, and CI variables for leaked NHI secrets and revoke them immediately. Assess third-party package trust, provenance, and revocation paths before allowing them into the SDLC. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article’s threat pattern includes secret theft and downstream abuse of that access. |
| Recommendation — Map package-malware detections to credential access and exfiltration techniques in your threat hunts. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest is Protected | Build artifacts and tokens must be protected from unauthorised exposure or tampering. |
| Recommendation — Protect build artifacts, dependency data, and secrets with controls that prevent disclosure or modification. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Pipeline tokens and registry credentials require lifecycle control when supply-chain trust is compromised. |
| Recommendation — Manage CI/CD authenticators with rotation, revocation, and inventory controls that match their privilege. | ||
Key terms
- Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
- 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.
- Behavioural Package Analysis: A method of assessing software packages by observing what they do at install time or during execution rather than relying only on published vulnerability data. It helps identify suspicious behaviour earlier, but it still needs remediation workflows to translate detection into risk reduction.
- CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
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. The course helps security teams connect machine identity, delegated access, and governance decisions across modern delivery pipelines.
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