Open-source dependency risk now extends beyond CVEs

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Anchore's blog post: CVE-based scanning is too narrow for modern open-source supply chain governance, with abandoned projects, delayed fixes and AI-hallucinated dependencies serving as risk signals.

Why it matters: It matters to IAM, NHI and application security teams because software trust now depends on component provenance, lifecycle state and policy enforcement, not just whether a package has a known vulnerability.

Context

Open-source software now makes up much of the application stack, which means security teams inherit risk from components they did not author and often do not fully govern. A CVE check only answers whether a known vulnerability is recorded; it does not answer whether the project is maintained, whether it still exists, or whether it is safe to trust in production.

That gap matters because software supply chain risk increasingly comes from provenance and lifecycle failures rather than only known exploits. When AI-generated code can hallucinate package names, the organisation needs a way to validate dependency reality, not just scan for disclosed vulnerabilities.

Key questions

Q: How do organisations decide when to trust an audited open-source dependency?

A: They should trust the dependency only after the audit, remediation, and release cycle are all visible. A report without a fix does not reduce exposure. The practical test is whether the maintainer has shipped a validated remediation and whether your own environment can confirm it is on the fixed path.

Q: What breaks when dependency governance is still treated as a scanner problem?

A: Teams end up with accurate inventories but no practical closure. They can identify vulnerable packages, yet still fail to determine which ones are reachable, which ones can be remediated safely, and which ones need to be fixed at the manifest rather than in source. That leaves the backlog growing while exploitable exposure stays live.

Q: How do AI-generated package names increase software supply chain risk?

A: They create a verification failure. If a developer copies a suggested import without checking whether the package is legitimate, attackers can publish a lookalike dependency and wait for it to be installed. The risk is not only malicious code, but the habit of trusting generated output before validating it against canonical package sources.

Q: Should organisations prioritise SBOM enrichment over more vulnerability scans?

A: Yes, when the problem is trust in third-party components rather than only known exploits. Vulnerability scans tell you what is already disclosed, while SBOM enrichment tells you whether the dependency should be trusted in the first place. For modern supply chains, lifecycle, provenance and maintainer signals often change the decision more than another CVE result does.

Technical breakdown

Why a clean CVE result does not equal a safe dependency

A CVE scanner answers a narrow question: has this component been assigned a known vulnerability? It does not tell you whether the package is maintained, whether its releases are stale, whether fixes arrive slowly, or whether the project has been abandoned. That is why dependency risk management has to treat vulnerability data as one signal, not the whole control. In supply chain terms, the issue is provenance and trustworthiness across the full component lifecycle, not only exploit presence. Practitioners need to combine vulnerability intelligence with package health, maintainer activity and release cadence to understand whether a dependency is structurally safe to consume. See the Open Source Security Guide. See the Open Source Security Guide.

Practical implication: Pair CVE scanning with package health checks before approving third-party dependencies.

How SBOMs expose dependency reality beyond the scanner view

An SBOM creates the inventory needed to move from assumptions to verification. By listing ingredients, teams can map what is actually present, then enrich that list with external signals such as repository activity, end-of-life status and release history. That makes it possible to distinguish a living dependency from a ghost project or a name-squatted package. The technical value is not the SBOM alone, but the workflow it enables: inventory, normalisation, enrichment and policy scoring. For software supply chain governance, this is the difference between knowing a package name and knowing whether it should be trusted at all. See the Open Source Security Guide.

Practical implication: Use SBOM enrichment to score package existence, maintenance and release freshness before deployment.

Why AI-hallucinated package names create a new supply chain attack path

AI code generators can invent plausible dependency names, and attackers can exploit that confusion by publishing malicious packages under those names. This is a software supply chain problem created by trust in generated output, not by a traditional vulnerability in the code itself. The failure mode is name-based assumption: developers copy a suggested import without verifying whether the package is canonical, legitimate or expected. Traditional vulnerability databases do not catch this because there may be no CVE and no prior reputation history. The control problem is therefore identity-like verification of software components before they enter build and deployment pipelines.

Practical implication: Require dependency verification for AI-suggested imports before they reach source control or build systems.

Threat narrative

Attacker objective: The attacker wants malicious code to be imported through normal development workflows so it can execute inside trusted software delivery pipelines.

1. Entry begins when a developer or build pipeline accepts a dependency suggested by AI-generated code or an unverified package reference.
2. Credential access is not the core issue here; the attacker instead abuses trust in package naming, publishing a malicious library that looks legitimate enough to be installed.
3. Impact follows when the poisoned dependency enters the software supply chain and becomes part of a deployed application or build process.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

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 trust is now the control problem, not just vulnerability discovery. The article shows that a package can be risky even when no CVE exists, because abandonment, end-of-life status and slow patching all undermine trust. That means security teams need to evaluate whether a dependency deserves inclusion at all, not only whether it is already known to be vulnerable. The practical conclusion is that software assurance has to move upstream into provenance, lifecycle and maintainership checks.

AI-generated dependencies create a verification gap that conventional scanning cannot close. When code generation invents a package name, the security decision is no longer about patching a vulnerable component but about validating whether the component is real, canonical and safe to consume. That is a governance problem disguised as a developer convenience problem. Teams should treat generated imports as untrusted until they are checked against source-of-truth package data.

SBOMs become more valuable when they are enriched, not when they are treated as static inventories. A bill of materials tells you what should be present, but the article’s real point is that you need runtime-quality intelligence about project existence, release cadence and maintainer activity. Static visibility without lifecycle context produces false confidence. The practitioner takeaway is to connect SBOM workflows to trust scoring and policy enforcement, not just compliance reporting.

Software supply chain risk now includes identity-like verification of packages and projects. The strongest intersection with identity here is not user IAM but the need to verify the authenticity and lifecycle of machine-consumed software components before they are trusted. That aligns closely with open source security governance, where package provenance and integrity are part of the approval decision. The practical conclusion is to govern dependencies as verifiable identities in the delivery pipeline.

From our research library:

• Software supply chain attacks were projected to cost organisations $60 billion in 2025.
• Read next: Open Source Security Guide

What this signals

Software provenance has become a governance signal, not a back-end hygiene detail. Teams that only optimise for CVE coverage will continue to miss abandoned packages, fake packages and dependencies that exist in name only. The operational shift is toward trust scoring of components before they are admitted into build and release paths.

Dependency identity is now part of application security decision-making. In practice, the question is no longer just whether a library is vulnerable, but whether it is authentic, maintained and expected. That means supply chain controls need to validate package identity the same way identity teams validate who or what is allowed to act inside a system.

For practitioners

• Build dependency trust scoring into approval workflows Combine CVE results with package age, release cadence, maintainer activity and end-of-life signals before a dependency is approved for use.
• Enrich SBOMs with source-of-truth metadata Map each listed component back to its canonical repository or package source, then attach lifecycle and maintenance indicators to the record.
• Block unverified AI-suggested imports Require review when code generation proposes dependency names, and reject packages that cannot be tied to an expected canonical source.
• Prioritise abandoned and end-of-life projects for removal Use policy enforcement to surface dependencies with no active maintainers, stale releases or end-of-life status ahead of routine CVE triage.

Key takeaways

• Open-source risk is no longer limited to disclosed vulnerabilities, because abandoned projects and fake packages can be just as dangerous.
• SBOMs become materially more useful when teams enrich them with provenance, maintenance and lifecycle signals.
• Security teams should treat dependency approval as a trust decision, not a pure vulnerability management exercise.

Related NHI Mgmt Group resources: Open Source Security Guide · Ultimate Guide to NHIs · Top 10 NHI Issues

Key terms

• 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.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Dependency Trust Scoring: Dependency trust scoring is the practice of combining multiple signals to decide whether a package should be accepted, restricted or removed. Those signals often include project age, maintainer activity, end-of-life status, release cadence and vulnerability exposure, rather than relying on CVEs alone.
• Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the broader security programmes that now depend on them.