Do not claim zero. A statement that your dependencies have no known vulnerabilities is true for a moment at most, and a customer's scanner will often contradict it. Describe your process instead: what you track, how you triage, and how you handle what remains open.
Why the claim fails
New advisories are published every day, so any component list can become vulnerable overnight without a single code change. OSV describes itself as an open, distributed vulnerability database for open source, and FIRST's EPSS publishes updated exploitation probabilities for CVEs daily. Both signals move constantly, which means an answer based on a snapshot ages quickly.
A customer who runs their own scan against your SBOM may find something within minutes. If you wrote "none", you are now the vendor who said something untrue.
A better formula
State four things.
- What you track. Direct and transitive components for each release.
- How you decide. Triage by severity, exploitation signal and reachability.
- What remains open. Findings not exploitable, awaiting upstream fixes or on scheduled upgrades, each with an owner.
- How you keep watching. Continuous matching against advisories after release.
Honest alternative phrasings
| Instead of | Say |
|---|---|
| "No vulnerabilities." | "No open findings above our urgent threshold in this release, as of date." |
| "We are fully patched." | "Known exploited issues in shipped components are remediated or mitigated." |
| "Our code is secure." | "We track and triage advisories for the components we ship." |
| "Scanners find nothing." | "Scanner findings are reviewed and closed with reasons or scheduled." |
Always attach a date, because the claim describes a point in time.
When the customer's scanner finds something
Treat it as a normal part of the conversation, not an accusation. Ask for the report, check whether the component is reachable and respond with the exposure analysis. The post on replying when a customer scans your SBOM walks through it.
Why this builds trust
Customers know software has flaws. What they test is whether you see them and respond predictably. A vendor who says "here are three open items, here is why they are low exposure, here are the dates" sounds more credible than one who says "none".
Preparing the replacement statement
Draft the replacement wording once and store it. A good version names the date of the last full check, the threshold you treat as urgent, the count of open items above that threshold and the owner of each. If the count is zero on that date, say so with the date attached. The difference from the old claim is that it describes a measured state at a time and not a permanent condition.
Try it yourself
Click through it at your own pace, or open it full screen.
See how many raw findings turn out to be unreachable. That analysis is the evidence behind a measured answer.
Safeguard provides reachability analysis and continuous matching of inventories to new advisories.
Quick check
Can we say "no critical vulnerabilities"?
Only with a date, a stated threshold and a scope. Even then, expect the customer to verify.
What if the customer demands zero findings?
Explain the triage model and offer a regular report. Zero is not a measurable promise.
Sources
Last reviewed: 19 October 2026.
