A clean scanner report tells you the tool found no known vulnerabilities in what it could identify, on the day it ran, in the scope chosen. It does not cover unidentified components, unknown flaws, vendored code, other repositories or later disclosures. Ask what was scanned, with which tool, and when.
Four ways a clean report can mislead
Scope. The report may cover one repository out of forty. Ask for the list of what was scanned and what was not.
Identification. Many scanners decide which known vulnerabilities apply by matching components to identifiers. OWASP Dependency-Check, for example, describes using evidence to identify a Common Platform Enumeration entry, and lists CVEs when one is identified. That means a dependency without an identifiable entry may show nothing, which looks like clean and is really unknown. The project page does not quantify how often this happens, so ask any tool vendor or your own team to test it on your stack.
Time. The scan is a snapshot. A new advisory the next morning changes the answer. Ask how often scanning runs and who watches new disclosures.
Knowledge. A scanner finds known issues. It says nothing about undisclosed flaws in the code itself, which is a different discipline.
Questions to ask next
- Which tool, which version, which database date?
- Which repositories, images and environments were in scope?
- Were vendored libraries, binaries and base images included?
- How are findings triaged: by severity score, exploitation status, or reachability?
- What was suppressed, by whom, and why? A report with a long suppression list can read as clean.
- How often does it run, and is it a gate or a report?
What a stronger answer looks like
| Weak answer | Stronger answer |
|---|---|
| "We run a scan before release" | "Scans run on every pull request and nightly on main" |
| "No critical findings" | "Zero open KEV listed findings, three high with documented reasons" |
| "We use an industry standard tool" | "Tool, version, scope and suppression log attached" |
| "Our dependencies are all up to date" | "Update lag report by package, plus reachability results" |
Reading a suppression log
A suppression is a decision to ignore a finding. Healthy ones have an owner, a reason, a date and a review date. Unhealthy ones say "false positive" with no detail and never expire. Ask to see a sample.
Try it yourself
Open the demo and look at how findings are managed over time, including how they are filtered and tracked. Note what the dashboard shows beyond a simple count.
Click through it at your own pace, or open it full screen.
Safeguard combines dependency scanning with reachability analysis and policy gates, and you can try a free scan to compare against whatever your team uses today.
Quick check
Is zero findings a good sign?
Sometimes. First confirm scope, tool coverage and suppressions. Zero from a narrow scan means little.
Should I run my own scan on the target?
Where the seller agrees, an independent scan is a useful cross check against their report.
Sources
Last reviewed: 19 October 2026.
