Kubernetes vulnerability scanning
Kubernetes vulnerability scanning identifies CVEs in the container images, OS packages, and language dependencies running inside a cluster. The current standard approach is SBOM-driven: generate a Software Bill of Materials per image (for example with Syft), then match that SBOM against CVE databases (NVD, vendor advisories, distro feeds) with a tool like Grype. The result is a list of vulnerabilities mapped to the exact pod and container where each one lives, which makes it possible to prioritize by blast radius, not CVSS alone.
How modern scanning works
- SBOM generation. A tool such as Syft reads each container image and extracts every package (deb, rpm, apk, npm, pip, gem, Go module, Java archive) with its version and PURL.
- CVE matching. A tool such as Grype takes the SBOM and matches against NVD and vendor-specific feeds (Alpine SecDB, Red Hat OVAL, Debian DSA, GitHub Security Advisories, and others).
- Context enrichment. Map each CVE back to the running pod, its namespace, its cluster, its exposure, and its permissions.
- Prioritization. Sort by exploitability, reachability, and blast radius, not just CVSS.
Why SBOM-based scanning is now the default
Older scanners ran filesystem-level tools (such as rpm -qa) on extracted images. They worked, with tradeoffs:
- Missed language-level packages (npm, pip) that sit outside OS package managers.
- Could not handle distroless images.
- Did not track vulnerabilities cleanly across distribution channels.
SBOM-based scanning is standardized (SPDX, CycloneDX), portable (one SBOM can feed many scanners), and storable. Retaining historic SBOMs means newly disclosed CVEs can be retroactively matched against old builds without re-scanning the images.
What to scan, and how often
- At build. Fail CI on new critical CVEs. This gates the supply chain.
- At registry push. Catches CVEs introduced via base image updates.
- At runtime, continuously. New CVEs are disclosed daily. An image that was clean when it was built may be vulnerable by the time it reaches production. Running clusters should be re-scanned against a fresh CVE database at least every few hours.
Prioritizing with reachability
A cluster with 10,000 CVEs is hard to distinguish from one with 100 until you know:
- Which CVEs are on an internet-exposed pod?
- Which pods have permissions that matter if compromised?
- Which packages are actually loaded at runtime (function-level reachability, where available)?
Graph-based KSPM platforms like Juliet answer those questions in one query. See attack path analysis for how the graph is used to rank findings.
Frequently asked about kubernetes vulnerability scanning
How is SBOM scanning different from Trivy or Snyk?
Trivy and Snyk both do SBOM-based scanning. They are scanners. SBOM is the input format they consume. The differences across scanners are coverage (which vuln feeds), matching accuracy (how they handle CPE noise), and integration (can they map back to running pods).
Should I store SBOMs?
Yes. When a new CVE is disclosed, stored SBOMs identify in minutes which historic builds were affected. Without them, the only option is re-scanning images if they still exist. Supply chain compliance (US federal, EU CRA) increasingly requires stored SBOMs.
What about zero-days not yet in NVD?
Good scanners pull from multiple feeds (NVD, GitHub Security Advisories, vendor distros, OSV) to reduce time-to-disclosure. For true zero-days, runtime detection is the relevant control. No static scanner can find what is not yet known.
Do I need to scan my own internal images differently?
Not really. SBOM tooling is registry-agnostic. What changes is authentication: the scanner needs credentials to pull from private registries. Scanning should respect existing registry RBAC.
How do I handle critical CVEs that are not actually reachable?
Suppress with rationale. Good scanners let you mark a CVE as not reachable (for example "the vulnerable function is never called") with an expiry date. Graph-based scanners often do this automatically by down-ranking findings without a reachable path.
See this in your clusters
Juliet maps your Kubernetes security posture as a graph and ranks findings by reachable attack paths, not just CVSS. Free tier, five-minute setup, no credit card.