Why the Same Container Yields Wildly Different Package Counts
At KubeCon Europe 2025, the same research pair showed that SBOM generation tools struggle with obfuscated container images. One finding went unquestioned in the room: the ground-truth vulnerability count ranged from 123 (Scout) to 1,164 (Trivy) for the identical base image. That is nearly ten times the spread. Both figures came from scanning the same container. This talk traces that discrepancy to its root causes and asks whether SBOMs produced by one tool can be safely consumed by another.
Two Sources of Inflated Package Lists
Tools that report more packages are not necessarily more thorough. Two patterns explain most of the gap. First, some tools list both the Debian source package and every binary it produces, effectively doubling entries. The shadow source package, for example, installs login, passwd, libsubid, and uidmap as separate binaries. Second, tools add miscellaneous packages that describe the SBOM container context rather than any real software component. Strip those two categories and the counts converge considerably.
Package URL Compatibility Drops to Zero Across Tools
When the researchers compared packages by name and version alone, the matrix showed broad agreement. Switching to full package URLs, compatibility fell to 0% off the diagonal. Every tool matched only itself. The culprit is inconsistent PURL encoding. Using python3-magic++ from Debian as a test case, the team found tools differing on percent-encoding of the + character, on epoch formatting in version strings, and on which optional qualifiers to include. The PURL spec is an ECMA standard. The tools are not following it.
CVE Counts Are Equally Unreliable
Cross-tool vulnerability scanning produced the sharpest finding. When a vendor SBOM generated by tool A is fed into tool B’s scanner, the result is zero CVEs in most combinations. The grayed-out cells in the compatibility matrix represent tools that do not support third-party SBOMs at all. Among the remaining combinations, near-zero results dominate. Three failure modes explain the outliers: CVEs flagged for Apple products appearing in Linux containers, deprecated vulnerabilities treated as fixed because a database was too current, and Alpine’s tracker listing only patched CVEs rather than all affected packages.
A Translation Script and an Open-Source UI
The team wrote a field-mapping script to normalize PURL fields across tools. After applying it, cross-tool vulnerability detection recovered from near-zero to substantial agreement across most tool pairs. Both the script and a comparison UI are open-sourced. The UI accepts a container name, returns a summary across all tools, and shows a 459-package bookworm breakdown where half the packages have conflicts. Drilling into any package reveals per-field differences: supplier typed as organization by one tool and person by another, license strings that do not match, and qualifier keys that differ entirely.
Q&A
Did any tool miss genuinely important CVEs, not just report extras? Yes, especially on Alpine where tools failed to flag vulnerable but unpatched packages, and on Debian when version strings included complex epoch and suffix combinations. â–¶ 27:31
Why SPDX instead of CycloneDX? All eight tools in the study supported SPDX, and the core problem sits in package URLs, which appear in both formats. â–¶ 28:44
Notable Quotes
compatibility goes to 0%. like only the diagonal which means like the same tool Jacopo Bufalino · ▶ 13:45
more vulnerabilities detected doesn’t mean better tooling. Jacopo Bufalino · ▶ 26:35
There is a standard. Use it. Come on, it’s there. Jacopo Bufalino · ▶ 23:21
if you give me an asbomb I use my own tooling then I find zero CVES Jacopo Bufalino · ▶ 21:47
Key Takeaways
- Vulnerability counts for the same image ranged 123 to 1,164 depending on the tool used.
- Full package URL compatibility across tools is 0%; name-and-version matching is far higher.
- A simple normalization script restores cross-tool CVE detection without changing any tool.
About the Speaker(s)
Agathe Blaise is a research engineer at Thales SIX GTS France (Gennevilliers). She holds a Ph.D. in Computer Science from Sorbonne University (2020) and an engineering degree from ISEN Lille (2017). Her research covers virtualization of network systems and security.
Jacopo Bufalino is a doctoral candidate at AL University and researcher at the CNAM Institute in Paris. He came to academia after industry work as a DevOps engineer, with a focus on cloud network security.