Zero-vulnerability software can honestly mean one narrow thing: no known, applicable vulnerabilities were found in a defined scope, by a named method, on a stated date. It cannot mean the code has no flaws. Unknown bugs exist in all software, so the phrase is only as good as its scope.
Known versus unknown
A scan reports vulnerabilities that someone has already found, written up and published in a database. Anything not yet discovered, or discovered but not disclosed, is invisible to it. A clean report therefore tells you about the state of public knowledge, not the state of the code.
That is still useful. Most real compromises start from known issues that nobody fixed. Getting the known list to empty is a worthwhile goal, as long as nobody mistakes it for proof of safety.
The four questions behind any zero claim
When you see "zero vulnerabilities" on a dashboard, a vendor page or an internal report, ask four things.
- Which assets are in scope? A zero for one service says nothing about the other forty.
- Which databases and which method? Package metadata, source analysis and container layers each find different things.
- What was filtered out? Some zeros are real, and some come from suppressing findings marked not exploitable or low severity.
- When was it measured? New disclosures arrive daily, so a zero from last week may be a handful today.
What a defensible version looks like
A defensible statement reads like this: "As of 19 October, scanning of repositories A to F against public advisory data shows no critical or high findings with a fix available, and two accepted exceptions are documented." It is less catchy and far more useful. Anyone can check it.
The NIST Secure Software Development Framework describes its goals in similar terms: reduce the number of vulnerabilities in released software, reduce the impact of ones that go undetected, and address root causes so they do not recur. Notice that it does not promise none.
Why severity and exploit likelihood matter
Even when the list is not empty, not every entry deserves the same urgency. FIRST describes EPSS as a probability that a published CVE will see exploitation in the next 30 days, and it is explicit that this is not a measure of severity or of risk in your environment. Use it as one input. Confirmed exploitation lives in CISA's catalog, so check that too.
The OSV schema shows another reason the number is fuzzy: whether a version counts as affected depends on how a database records ranges, and different sources can disagree. Two honest scanners can return different counts for the same package.
A practical target
Instead of chasing zero, set targets you can defend: no known exploited vulnerabilities in production, a fixed time to remediate by severity, and a short, reviewed exception list. Measure those every week.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Can any software have zero vulnerabilities?
No one can show that. Software can have zero known and applicable findings in a stated scope on a stated date, which is a narrower and verifiable claim.
Is a clean scan useless, then?
No. It shows you have cleared the known problems that attackers most often use. It just does not speak to unknown ones.
Sources
Last reviewed: 19 October 2026.
