Five myths cause most confusion about vulnerability scanners: that a clean scan means safe, that severity equals risk, that every finding is real, that scanners know your code, and that results only change when code does. Each has a simple correction rooted in how scanning actually works.
Myth 1: a clean scan means the software is safe
Fact. A clean scan means no known advisory matched the components the scanner could identify. Unknown components, unlisted files and undisclosed flaws all produce no findings. A scanner can only report what its inventory and its data contain.
Myth 2: severity equals risk
Fact. Severity describes a vulnerability in general. FIRST's CVSS guidance says Base metrics reflect intrinsic qualities that are constant over time and across environments, while Threat and Environmental metrics are where change and your own context come in. Public databases typically supply only the Base score. Risk needs exploit signals and your asset context too. See CVSS, EPSS and KEV compared.
Myth 3: every finding is real
Fact. Findings can come from wrong version detection, loose matching, withdrawn advisories, or aliases counted twice. Advisory quality varies as well: GitHub notes its unreviewed advisories come straight from the NVD feed and are not checked for validity or completeness, which is why they do not trigger Dependabot alerts. A finding is a candidate until checked. For the main failure modes, read false positives and false negatives.
Myth 4: the scanner understands how your code uses a library
Fact. Basic matching works at the package level. It knows you have version 2.3.1, not whether you call the vulnerable function. Reachability analysis adds that, but it needs source or build information and still has limits with reflection and dynamic loading.
Myth 5: results only change when code changes
Fact. New advisories, withdrawn ones, corrected ranges and daily exploit scores all change results with identical code. EPSS, for example, updates daily and estimates exploitation probability over the next 30 days. A finding's priority can move overnight.
Quick summary table
| Myth | What actually happens |
|---|---|
| Clean scan means safe | Only identified components are checked against known advisories |
| Severity is risk | Severity is one input; context and exploitation matter |
| Findings are all real | Matching and data quality produce false positives |
| Scanner knows code usage | Package-level unless reachability analysis is used |
| Results track code changes | Data changes alone can alter results |
What to do with this
- Read the scan scope in every report.
- Record the source and version of each score.
- Verify a sample of findings by hand each quarter.
- Rescan stored inventories on a schedule.
- Treat priority as something that can change.
Try it yourself
Click through it at your own pace, or open it full screen.
Pick a finding and see how exploitability questions change what you do about it.
Where Safeguard fits
Safeguard pairs SBOM and dependency scanning with reachability analysis and policies, aimed at the gaps these myths describe. You can run the free scan to test them on your own project.
Quick check
Is a scanner with zero findings broken?
Not necessarily. Check the inventory size and what was scanned. Zero findings on a fully identified, current project can be accurate.
Which myth costs teams the most?
Treating a clean scan as proof of safety, because it removes the incentive to check coverage.
Sources
Last reviewed: 19 October 2026.
