Mind the Match: Why Vulnerability Matching Is Harder Than You Think
summary
Scanning the same Red Hat 8 image returns 852 vs 3,719 findings because different tools and SBOM metadata choices disagree — experiments show 80.5% divergence between Grype and Trivy and a 66% loss of findings when mismatching SIFT vs Trivy SBOMs. Concrete failure modes include kernel-headers noise, setuptools being missed, and a Tomcat JAR mapped to wrong Maven qualifiers. Practical steps: check which database (NVD, OSV, vendor advisories) produced the match, verify package presence and version, document and reuse false-positive suppressions, and map your SBOM generator to your scanner.
AI-written summary · about
chapters (8)
- 0:00Vulnerability matching intro
- 1:07Scanner outputs can't be trusted
- 3:35CPEs and PURLs failure modes
- 6:22Scanner disagreements on findings
- 10:54SBOM generator and scanner problems
- 15:09Vulnerability verification workflow
- 17:55Scaling vulnerability matching
- 20:22Summary
related talks
24mOvercoming CVE Shock - Adding Perspective in Vulnerability Scanning
43mA radiography of a SBOM vulnerability scanner
29mUnlocking the Power of SBOMs: A Deep Dive into Risk Management and Cybersecurity Posture
39mTrust but Verify: Uncovering the Hidden Risks of Inaccurate SBOMs With J...
50mChallenges in Open Source Software Identification
42mComparison and Proposal of Vulnerability Management Approaches in Yocto-Based...
21mSecuring Diverse Supply Chains Across Interconnected Systems
21mDevSecOops: 15 years of DevOps and patching is still horrible