Open-source dependencies: are CVE checks enough anymore?

TL;DR: Vulnerability databases alone miss major open-source supply chain risk, because abandoned projects, end-of-life packages, delayed fixes and AI-hallucinated dependencies can all create exposure without a CVE, according to Anchore research. The governance gap is not detection, but proving that third-party components actually exist, are maintained and remain trustworthy.

Editorial analysis by NHI Mgmt Group, based on content published by Anchore: “Why Vulnerabilities Aren’t Enough: Threat Hunting Your Open Source Code”.

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.

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

A: Teams end up with accurate inventories but no practical closure.

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

A: They create a verification failure.

Practitioner guidance

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

Bottom line: Open-source risk is no longer limited to disclosed vulnerabilities, because abandoned projects and fake packages can be just as dangerous.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →