Zero-CVE packages can still wreck your software supply chain

Key Takeaways

• A zero-CVE scan result often means no one is auditing the package, not that it's secure
• 95% of vulnerabilities come from transitive dependencies buried deep in your dependency tree
• Abandoned packages without active maintainers represent a larger threat than packages with disclosed CVEs

Your dependency scanner shows zero CVEs. Green checkmarks across the board. Ship it. Except that clean bill of health might be the most dangerous signal in your entire security workflow. The absence of known vulnerabilities in a package tells you almost nothing about its actual security posture, and teams that treat zero-CVE as a seal of approval are building on foundations they don't understand.

Software supply chain attacks increased 742% between 2019 and 2022, according to Sonatype's State of Software Supply Chain report. The attackers aren't targeting packages with well-documented CVEs. They're exploiting the blind spots: abandoned projects, transitive dependencies six layers deep, and packages that look clean because nobody is looking at them.

Why zero CVEs can mean zero oversight

A CVE exists because someone found a vulnerability, reported it, and it went through a formal disclosure process. That process requires active maintainers, security researchers paying attention, and infrastructure to handle reports. Abandoned packages don't get CVEs because no one is auditing them.

Consider the math. Synopsys reports that 97% of modern applications contain open source code. In 2023 alone, researchers discovered over 29,000 new open source vulnerabilities. But the packages getting CVEs assigned are the actively maintained ones with security teams. The npm package last updated in 2019 with 50 weekly downloads? It doesn't have CVEs because it doesn't have eyes on it.

The transitive dependency problem

Here's the number that should keep you up at night: 95% of vulnerabilities come from transitive dependencies, according to Snyk's research. These are the packages you didn't choose. They're the dependencies of your dependencies, pulled in automatically, often without appearing in your lock file in any obvious way.

The average critical vulnerability hides six dependencies deep in your tree. Your direct dependency looks fine. It depends on a utility library that depends on a parsing library that depends on a string manipulation package that someone wrote in 2016 and hasn't touched since. That's where log4shell lived. That's where the next log4shell is waiting.

Your scanner reports on direct dependencies with known issues. It can't tell you that a package three layers down has fundamentally insecure design patterns, hardcoded credentials in test files that shipped to production, or cryptographic implementations written before constant-time comparison was standard practice.

What attackers actually exploit

Supply chain attacks don't rely on CVEs. They rely on trust. Typosquatting puts malicious packages one character away from legitimate ones. Dependency confusion exploits how package managers resolve internal versus public package names. Account takeovers compromise maintainer credentials on packages with millions of weekly downloads.

None of these attack vectors show up in a CVE scan. The malicious code is intentional, not a bug. It was designed to exfiltrate environment variables, inject cryptominers, or establish persistence. By the time someone notices and the package gets pulled, it's been downloaded thousands of times.

What actually reduces supply chain risk

CVE scanning is table stakes. It catches known issues in maintained packages. That's valuable, but it's the floor, not the ceiling. A mature supply chain security posture requires additional layers.

• Generate and maintain a Software Bill of Materials (SBOM) for every release. You can't secure what you can't see.
• Track maintainer activity and project health, not just vulnerability counts. A package with 10 patched CVEs and active maintainers is safer than a package with zero CVEs and no commits in three years.
• Pin dependencies to exact versions and audit updates before merging. Automated dependency bumps are a common attack vector.
• Use private registries that mirror and scan public packages before they enter your environment.
• Implement runtime monitoring to detect anomalous behavior from dependencies, regardless of CVE status.

Tools like Chainguard, Snyk, and Sonatype provide supply chain intelligence beyond CVE counts. They track maintainer reputation, detect typosquatting, and flag packages with suspicious update patterns. The cost of a data breach averaged $4.45 million in 2023, according to IBM. The tooling investment pays for itself.

The governance gap

Most organizations have no formal process for approving new dependencies. A developer needs a JSON parser, finds one on npm, adds it to package.json, and now it's part of your attack surface forever. That decision, made in 30 seconds to solve an immediate problem, creates long-term security debt that compounds silently.

Dependency governance doesn't mean bureaucratic approval processes that slow development to a crawl. It means establishing criteria: minimum maintainer activity, license compatibility, download thresholds, and security disclosure policies. Automate enforcement in CI/CD so the guardrails exist without manual review bottlenecks.

Frequently Asked Questions

What is a transitive dependency and why does it matter for security?

A transitive dependency is a package that your direct dependencies rely on. You didn't add it to your project, but it's running in your environment. These indirect dependencies account for 95% of vulnerabilities because they're often overlooked in security reviews.

How can a package with zero CVEs still be a security risk?

Zero CVEs typically means no one has audited the package and reported findings through the formal disclosure process. Abandoned packages, malicious packages, and packages with poor security practices may never receive CVE designations.

What should I look for beyond CVE counts when evaluating dependencies?

Evaluate maintainer activity, commit frequency, response time to issues, security disclosure policies, download trends, and the package's own dependency tree. A well-maintained package with patched CVEs is safer than an abandoned package with none.

How do software supply chain attacks bypass CVE scanning?

Attacks like typosquatting, dependency confusion, and maintainer account takeovers inject intentional malicious code rather than exploiting bugs. Since the malicious behavior is by design, it doesn't receive a CVE until after discovery and removal.

Source: The New Stack / Adrian Bridgwater