Safeguard
Security Guides•

Reporting zero vulnerabilities honestly: what the number can claim

Zero findings means a scan found nothing, not that nothing exists. Learn how to word it, what coverage to state and which caveats belong beside it.

Safeguard Security Team
3 min read

Zero findings means the scans you ran did not detect anything within their scope and rule set. It does not mean zero vulnerabilities exist. Report it with the scope, the date and the scan types, and say what was not covered.

Absence of evidence

A scanner only reports what it knows how to detect, in the files and assets it sees, using the advisory data it has at that time. A clean result today can turn into a finding tomorrow when a new advisory is published for a package you already ship.

That is why "no known vulnerabilities as of date" is a more accurate phrase than "no vulnerabilities".

What to state next to the number

A clean report needs five qualifiers:

  1. Scope: which repositories, images or services.
  2. Scan types: dependency, source, container, dynamic. Others are not covered.
  3. Date and time of the scan, and the advisory data refresh time if you have it.
  4. Exclusions and suppressions: how many, and why.
  5. Method for severity filtering: was a threshold applied, so lows are hidden?

If any of those is missing, readers will fill the gap with the most optimistic reading.

Check that zero is not a failure

Zero can come from a broken scan. A manifest that was not parsed, an expired credential, or a path filter that skips all code can all produce a clean result. Add a sanity control: a known test file with a deliberate finding that must show up. If it does not, the pipeline is broken.

Also compare run history. A repository that normally has 30 findings and suddenly has none deserves a look before a celebration.

Suppressions can empty the report

Large ignore lists make zero cheap. Report the number of active suppressions with their ages next to the finding count. A growing list is a trend to watch. See Goodhart's law in security metrics.

Wording that holds up

Good: "As of 19 October, dependency and container scans of the 42 production services reported no open items above the medium severity threshold. 3 suppressions are active, oldest 12 days."

Poor: "Our software is secure."

The first is checkable. The second cannot be defended.

For customers and auditors

If a buyer asks for proof, offer the scan summary with scope and date, and offer to run a fresh one. Do not use words like certified or guaranteed. Honest limits increase trust more than absolute claims do.

Handling a customer who wants a guarantee

Some buyers ask for a statement that the product has no vulnerabilities. You cannot give one honestly. Offer instead a dated summary of scans, your remediation policy with its tiers, and a statement of how you handle new advisories. This answers the real question, which is how you behave when something is found.

Keep the wording consistent across sales, support and documentation, so nobody contradicts the careful version in a rushed email.

Quick check

Can a dashboard show a green tick for zero findings?

Yes, if the tick also shows scope, scan date and suppression count on hover or beside it.

How fresh should a zero report be?

As fresh as the pace of new advisories in your ecosystem. A daily or per build check is common for production services.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.