Vulnerability scanners are essential tools in modern platform engineering, but their reports can be confusing, overwhelming, or even contradictory. Understanding how container SBOM vulnerability scanning works - and how to interpret findings critically - is what separates teams that manage risk effectively from those drowning in alert noise.

Main insights

• Vulnerability scanners operate in two stages: generating a Software Bill of Materials (SBOM) and matching it against vulnerability databases - understanding both stages is essential for interpreting results accurately
• Different scanners can report vastly different findings for the same asset based on scope (OS packages vs. application dependencies), which can mask actively exploited vulnerabilities
• Prioritization frameworks like EPSS and SSVC help you focus remediation on what actually poses real risk, not just what scores highest on paper
• Minimal container images and automated dependency updates can reduce vulnerability counts by 90% or more, making your remaining findings far more actionable

Neil Carpenter, Field CTO at Minimus and a veteran security engineer with over a decade of incident response experience at Microsoft, recently led a practical deep dive into vulnerability management for platform engineers. His hands-on approach demystifies CVE reports, scanner outputs, and the prioritization decisions that actually move the needle on security posture.

You can watch the full discussion here if you missed it: How to watch the watcher: Investigating vulnerability scanner reports 101.

The scanner discrepancy problem: When 673 doesn't equal 2

One of the most striking examples Carpenter shared involved a customer who received two wildly different vulnerability reports for the same asset. One scanner reported 673 vulnerabilities; another reported just 2. This wasn't a misconfiguration - it revealed a fundamental difference in what each scanner was examining.

"One platform was only looking at OS packages," Carpenter explained. "It was only looking at what you might apt-get install, and they were running apt-get update and apt-get upgrade -y regularly. So there were only two things that were unpatched there. It was not looking at any of the language vulnerabilities in the Node.js application that lived on that asset, of which there were 671 other vulnerabilities, several of which were known to be exploited in the wild."

This case makes clear that the headline number in a scanner report is meaningless without understanding its scope. You must verify whether your scanner examines:

• OS packages installed via apt, yum, or apk
• Application-level dependencies such as Python packages, Node modules, Java JARs, and Go modules
• Compiled binaries and their embedded dependencies
• Configuration files and infrastructure-as-code definitions

How scanners actually work: SBOM generation and matching

Understanding the two-stage scanning process helps you troubleshoot discrepancies and optimize your vulnerability management workflow.

Stage 1 - SBOM generation. Scanners like Syft or Trivy first catalog everything in your container image, VM, or codebase. Carpenter demonstrated this with Syft, which found 479 packages, 400 executables, and over 21,000 files in a standard Python image. The scanner reads OS package metadata, language-specific dependency manifests (package.json, requirements.txt, go.mod, pom.xml), and compiled binary manifests.

Stage 2 - Vulnerability matching. The scanner compares this inventory against vulnerability databases, matching package names and versions to known CVEs using CVSS scores, CPE ranges, and vendor advisories.

This two-stage process also explains why certain common practices can blind your scanners:

• Compiling binaries yourself and copying them in - rather than installing via package managers - may prevent version matching
• Clearing package manager caches removes the metadata scanners need to identify packages
• Cherry-picking vulnerability patches into custom builds means scanners won't recognize that specific issues have been fixed

Reading CVE bulletins like a pro: The three critical fields

When you receive a vulnerability report, three machine-readable fields matter most.

CVSS score measures potential severity on a 0-10 scale. Carpenter used Log4Shell (CVE-2021-44228) as an example - it scored a perfect 10.0 and lived up to that rating by being trivially exploitable across countless Java applications. However, many critical-severity vulnerabilities only reach that rating under specific configurations. "These are scored on how absolutely potentially bad the vulnerability could be, not how bad it is typically," Carpenter noted.

CPE (Common Platform Enumeration) entries tell you exactly which software versions are affected. For Log4Shell, this meant Apache Log4j versions 2.0 through 2.15.0. Understanding CPE ranges lets you quickly determine whether your systems are actually vulnerable without wading through prose descriptions.

CWE (Common Weakness Enumeration) classifications describe the type of weakness - improper input validation, deserialization flaws, resource consumption issues. While less immediately actionable, CWEs help you identify patterns in your vulnerability landscape over time.

The NVD enrichment gap and what it means for you

In January 2024, the National Vulnerability Database (NVD) stopped enriching most vulnerability records with CVSS scores and CPE data. The industry didn't notice until February, and the resulting confusion rippled through security teams worldwide.

Carpenter demonstrated this with a recent NGINX vulnerability. The CVE record showed a CNA (CVE Numbering Authority) score from F5 Networks but lacked traditional NVD enrichment. More critically, the default interface view showed a CVSS 3.x score of 8.1 (high), while F5 had also provided a CVSS 4.0 score of 9.2 (critical) - a difference that could lead teams to significantly underestimate severity.

The good news: most vulnerability scanners have adapted by pulling from multiple sources, including CISA's Authorized Data Provider (ADP) program, vendor advisories, and community databases like GitHub Security Advisories. You must verify that your scanners are pulling from these alternative sources and not relying solely on NVD.

Prioritization: Moving beyond "patch everything critical"

When Carpenter scanned a standard Python container image, it returned roughly 1,200 vulnerability findings. No team can realistically address that volume. Research from Cyentia shows that organizations typically patch about 10% of new vulnerabilities each month, regardless of whether they receive 100 or 100,000 findings. "If your goal is to patch everything, you're about as effective as patching nothing because you're getting about 10% done," Carpenter observed.

Two frameworks cut through the noise effectively:

EPSS (Exploit Prediction Scoring System) predicts the likelihood a vulnerability will be exploited in the next 30 days. Only about one in 40 vulnerabilities is ever exploited in the wild, but EPSS v5 achieves roughly 63% accuracy in predicting which ones will be - a significant improvement over relying on severity scores alone.

SSVC (Stakeholder-Specific Vulnerability Categorization) uses a decision tree approach:

1. Is this vulnerability known to be exploitable?
2. If exploitable, does it provide full or partial system control?
3. How severe would exploitation be in your specific environment?
4. What is the potential impact on what an attacker could access?

Based on these answers, vulnerabilities are categorized as "track," "track more closely," "attend," or "act immediately." Carpenter praised this framework for its inversion of the typical approach: "Starting with is it known to be exploited and then moving forward from there means that you cut out a lot of noise. You really get right to what's critical."

Practical remediation: Minimal images and automated updates

Carpenter's most actionable advice centers on reducing attack surface before vulnerabilities appear. By rebuilding the standard Python image to include only essential packages, he reduced the package count from 479 to 23 - and the vulnerability count dropped proportionally. "When we rebuild it, it has 23 packages in it, only what's really necessary for me to run my Python applications," he explained.

For ongoing dependency management, Carpenter recommended automating patch-level updates through your CI/CD pipeline:

• Automatically create pull requests when patch versions are available (for example, updating Django 5.1.6 to 5.1.15)
• Run updates through comprehensive automated testing before merging
• Require human review for minor or major version bumps that may introduce breaking changes

"If you already have good testing, this is a reasonable approach to start looking at," he said. "If you don't have good testing, I think you're inviting a world of hurt."

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.

Key takeaways

• Verify what your scanner actually scans. A scanner that only checks OS packages will miss language-level vulnerabilities that may be actively exploited. Confirm your tooling covers both OS packages and application dependencies before trusting any report's headline number.
• Use EPSS and KEV data to prioritize remediation. Focus first on vulnerabilities with known exploits or high exploitation probability. Severity scores alone are a poor proxy for actual risk - data-driven prioritization frameworks like EPSS and SSVC are far more effective.
• Reduce attack surface with minimal container images. Stripping unnecessary packages from base images can cut vulnerability counts by 90% or more, making the remaining findings manageable and genuinely actionable rather than an endless backlog.
• Automate dependency updates with strong testing guardrails. Automatically creating pull requests for patch-level updates and running them through CI/CD dramatically reduces manual remediation work - but only if you have comprehensive test coverage to catch regressions before they reach production.