Stop managing vulnerabilities and start managing scanner assumptions

Date:
Mon, 01 Jun 2026 10:04:54 +0000

Description:
Run two industry-standard scanners on the same container image and you will get two entirely different answers.

FULL STORY ======================================================================Copy link Facebook X Whatsapp Reddit Pinterest Flipboard Threads Email Share this article 0 Join the conversation Follow us Add us as a preferred source on Google Newsletter Subscribe to our newsletter 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. Lexi Selldorff Social Links Navigation

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. Latest Videos From You may like Why traditional metrics are giving CISOs a false sense of security The open source blind spot in our supply chains Convergence isnt optional: The new mandate for IT and security

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. Are you a pro? Subscribe to our newsletter Sign up to the TechRadar Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed! Contact me
with news and offers from other Future brands Receive email from us on behalf of our trusted partners or sponsors By submitting your information you agree to the Terms & Conditions and Privacy Policy and are aged 16 or over.

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. What to read next Proof over promises: a new doctrine for cybersecurity Patch window is officially dead as AI finds bugs faster than humans can squash them AI code security risk: The need for a smarter layer between detection and remediation

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



======================================================================
Link to news story: https://www.techradar.com/pro/stop-managing-vulnerabilities-and-start-managing -scanner-assumptions


--- Mystic BBS v1.12 A49 (Linux/64)
* Origin: tqwNet Technology News (1337:1/100)