No. Zero CVEs means no vulnerability has been published for the package, not that none exists. The count reflects how much attention a project has received and how its maintainers report flaws. Use it as one input next to maintenance, review practice and provenance signals.
Myth versus fact
| Myth | Fact |
|---|---|
| No CVEs means no flaws | It means no published flaws. Unreviewed code can hold bugs nobody has reported |
| Many CVEs means a bad project | A busy, widely used project often has many reports because people look hard and the maintainers disclose |
| One clean scan means safe | A scan checks known issues at one moment. New advisories land later |
| CVE count ranks packages | Counts are not normalized for size, age or audience |
Why a zero can be a weak signal
A CVE is created when someone reports a flaw and it goes through assignment and publication. That depends on people looking and on maintainers choosing to disclose. A small package that nobody audits can stay at zero for years. A new package starts at zero by definition.
The OpenSSF Concise Guide lists vulnerability status as one of many checks, and puts it beside things like security response, vulnerability reporting instructions and security audits. Its security response rule asks whether the project fixes bugs, especially security bugs, in a timely manner. A project with a documented reporting path and a record of fixes is arguably more trustworthy than a silent one with an empty list.
Why a high count can be a weak signal too
Counting advisories rewards projects that hide problems and punishes projects that report them. The better question is what happened after each report: how long the fix took, whether older release lines got patches, and whether the advisory text was clear. The deps.dev API can list advisories that affect a given package version, which is a starting point for that review.
What to check next to the count
- Is the project maintained? The Scorecard Maintained check looks for commits across the previous 90 days and gives the lowest score to archived projects.
- Is there a way to report a flaw? The Security-Policy check looks for a SECURITY.md file with contact details.
- Are changes reviewed? The Code-Review check looks at roughly the last 30 commits for approvals.
- Is this the package you meant? Look at the creation date, popularity and similarly named packages.
- Is the version you are about to install affected by anything today? Rescan on a schedule, because the answer changes.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that findings arrive over time, which is why a single clean result does not stay clean.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning with reachability analysis, so you can see which known issues matter in your code, and policies and gates to act on them. A free scan is at gold.safeguard.sh/scan.
Quick check
Should I avoid a package with many CVEs?
Not automatically. Look at how quickly fixes shipped and whether the affected versions are ones you use.
How often should I recheck?
On every build and on a schedule, because new advisories are published against versions you already shipped.
Sources
- OpenSSF Concise Guide for Evaluating Open Source Software
- OpenSSF Scorecard check documentation
- deps.dev API v3 documentation
Last reviewed: 19 October 2026.
