By estherdidsang@gmail.com 
Security leaders have invested heavily in vulnerability management programs. Scanners are running. SBOMs are being generated. Dashboards are showing numbers. And yet, most programs are operating on a foundational assumption that does not hold: that scanner output is authoritative. It is not.
Run two industry-standard scanners on the same container image and you will not get two versions of the same answer. You will get two entirely different answers. In a recent experiment using a Red Hat 8 image, Grype surfaced 852 CVEs while Trivy surfaced 3,719.
Head of Engineering at Manifest.
That is an 80.5% divergence, on identical input, at the same point in time. Both scanners are working correctly. They are just making different decisions, and most organizations have no idea which decisions their scanner is making on their behalf.
This is not a tooling problem you can fix by switching vendors. It is a structural problem with how vulnerability matching works, and understanding it is now a requirement for any security leader who wants their program to produce reliable signal.
Why matching is harder than it looks
Every scanner follows the same basic pipeline: identify the packages in a container or repository, assign each package an identifier, then match that identifier against a vulnerability database. The output is a list of CVEs with scores and fix information. The matching step is where programs quietly fall apart.
Packages are identified using one of two formats: CPEs (Common Platform Enumerations) or PURLs (Package URLs). CPEs are required for NIST’s National Vulnerability Database (NVD) and therefore required for most compliance frameworks. But their vendor and product fields are freeform.
Forks and repackaged distributions routinely break attribution. Three distinct Google protobuf repositories, for instance, share the same CPE. PURLs are more ecosystem-aware and increasingly preferred by modern advisories, but their qualifier fields are completely unstandardized, and every scanner uses them differently.
The database your scanner queries compounds the problem further.
NVD is manually curated, CPE-only, and enrichment often lags by weeks or months. OSV is ecosystem-native with faster updates but uneven coverage across ecosystems.
Vendor advisories like Red Hat’s are often most accurate for their packages, but their data does not always make it back into NVD, and they are not formatted for universal ingestion.
Each of these mismatches is a place where your scanner makes a quiet decision. Most of those decisions are never surfaced to the teams acting on the output.
The decisions your scanner is making without you
The divergence between Grype and Trivy is not random noise. It is structured, and understanding the structure is what separates a mature program from one that is just generating numbers.
Trivy flagged 2,974 CVEs for a kernel headers package. Grype flagged zero, because it applies a default suppression rule: kernel headers is a headers-only dev package, and the assumption is that its presence does not expose you to the Linux Kernel CVEs it is linked to.
That is a reasonable judgment call. Your team may agree with it or not. But your program should know it is being made.
Grype flagged three CVEs for Python setup tools. Trivy flagged none, because it did not catalog those packages during the scan. Trivy flagged 16 CVEs for a Tomcat Catalina jar. Grype flagged zero, because it inferred the Maven Group ID from the directory path and got it wrong.
In each case, a different scanner is more correct. In each case, the correction is invisible unless you know to look.
The SBOM generator problem nobody talks about
If your program relies on SBOMs, whether vendor-provided or internally generated, the problem extends upstream of the scanner. The tool that generated the SBOM shapes what the scanner can find.
Scanning the same container image but using a Syft-generated SBOM versus a Trivy-generated SBOM produces a 66% difference in Grype’s output. Syft injects upstream package qualifiers into its PURLs, allowing the scanner to match a minimal package against its parent’s vulnerability history.
Trivy omits those qualifiers. Grype finds nothing. The vulnerability gap is not in the scanner. It is in the metadata the generator chose to include.
This means a vendor-supplied SBOM scanned with a mismatched tool may give you a false confidence in that component’s security posture. SBOM format matters too: CycloneDX and SPDX, the two dominant formats, produce meaningfully different results from the same toolchain due to how each handles extended package metadata.
What security leaders should do now
Three decisions that will immediately improve program reliability:
Audit your toolchain pairing. Identify which SBOM generator produced each SBOM in your environment and verify that the scanner consuming it was built for that generator. Syft pairs with Grype. Trivy generates and scans as a unified tool. Mixing them silently degrades coverage.
Know where your CVSS scores come from. If your program gates remediation priority on severity thresholds, understand which CNA your scanner defaults to. Grype uses NVD scores.
Trivy often uses vendor scores, which reflect vendor-specific mitigations. The same CVE can be rated critical by one and medium by the other. Your escalation policy may be triggering on the wrong signal.
Build suppression rules, not just fix queues. One documented suppression rule applied at fleet scale eliminates thousands of manual reviews. When your team validates that a finding is a false positive, codify that judgment and generalize it.
A suppression library compounds in value the same way a vulnerability backlog does, but in the right direction.
The honest audit question
A clean scan is not confirmation that your environment is secure. It may mean the scanner missed something, or that the generator omitted metadata the scanner needed, or that the database has not caught up to a recent advisory. Zero findings require interpretation, the same as 3,000 findings do.
The programs that will hold up under scrutiny are not the ones running the most scanners. They are the ones that know what assumptions their scanners are making and have built workflows to surface and challenge those assumptions.
That is what mature vulnerability management looks like in practice.
We’ve featured the best encryption software.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit