Treat a zero-vulnerability promise as a claim to test, not a feature to buy. Ask what is in scope, how it is measured, how fast new issues are handled and what happens when the promise fails. A vendor with a real process can answer all four in writing.
Why the phrase appears
It sells well. Buyers are tired of long findings lists and want the list gone. Providers who curate or patch components can honestly offer something close to it for their own catalog, under conditions. The risk is the version with no conditions.
Scope questions
- Which components, versions and ecosystems does the promise cover?
- Does it include transitive dependencies and base images?
- Does it cover your code, or only the third party packages?
- Does it hold across the whole support window or only at the moment of delivery?
Measurement questions
- Which advisory sources define a vulnerability, and are they listed?
- Are findings that are not exploitable counted, excluded or marked?
- Who decides what is excluded, and is the exclusion list visible to you?
- Is the measurement repeatable by your own scanner?
The last one matters most. If your tool disagrees with theirs, you need a documented way to resolve it.
Response questions
A zero is a snapshot, so the commitment that matters is how fast the snapshot is restored. Ask for time to publish an advisory, time to ship a fix, and what is done when no fix exists upstream. Ask whether the fix is a backport or a version bump, and whether you get machine-readable data about it.
Accountability questions
CISA's Secure by Design material says producers should take ownership of product security instead of shifting the burden to customers. Apply that to the contract: what remedy exists if the promise is missed, and is it a credit, a fix commitment or nothing?
Wording that should worry you
- "Guaranteed secure" or "vulnerability free" with no scope.
- No named data sources.
- A proprietary score that cannot be reproduced.
- Reluctance to share a sample advisory or changelog.
Reasonable alternatives
Ask for a service level on response time by severity, a reproducible scan result on a sample, and a transparent exclusion list. The NIST Secure Software Development Framework is a useful shared vocabulary: ask which of its practices the vendor follows and how they show it.
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
Is a zero-vulnerability promise ever honest?
It can be, if it is scoped, tied to named data sources, measured on a date and backed by a response commitment.
What single document should I request first?
A recent advisory or changelog for a real fix, so you can see how they describe scope, severity and the patch itself.
Sources
Last reviewed: 19 October 2026.
