Container Image Vulnerability Density Benchmark

Container image vulnerability density benchmarks measure how many known vulnerabilities an image carries, weighted by severity and normalized so images of different sizes can be compared. Containers bundle an operating system layer, runtime, and application dependencies, each of which can contain known Common Vulnerabilities and Exposures (CVEs). Tracking vulnerability density turns a sprawling supply-chain problem into a comparable, trackable metric.

Because base images and dependencies are shared across many services, a vulnerable base multiplies risk across an entire fleet.

What It Measures

Core metrics include vulnerabilities per image by severity (critical, high, medium, low), vulnerability density (vulns normalized by package count or image size), fixable ratio (share of vulnerabilities with an available fix), and base-image debt (vulnerabilities inherited from the base versus introduced by the application). The fixable ratio is especially actionable because it separates addressable issues from those awaiting upstream patches.

Methodology

Container scanners (such as Trivy, Grype, or registry-integrated scanners) inspect each image layer, build a software bill of materials of OS packages and language dependencies, and match them against vulnerability databases. The benchmark records counts by severity, identifies which vulnerabilities have fixes, and attributes each to the base image or application layers. Normalizing by package count or megabytes yields density so a large image is not unfairly penalized. Scans run in CI on every build and continuously on stored images, since new CVEs are disclosed against unchanged images over time. Comparing density across images and over time reveals which bases and dependencies drag down the fleet.

How to Interpret Results

Lead with critical and high counts and the fixable ratio, not the raw total, because many low-severity or unfixable issues add noise. A high fixable ratio means most risk can be eliminated immediately by updating packages or rebasing. High base-image debt points to switching to a slimmer or better-maintained base (minimal or distroless images carry far fewer packages and thus fewer vulnerabilities). Density normalizes across image sizes, so a small image with high density is genuinely worse than a large one with the same raw count. Track the trend, since unchanged images accumulate vulnerabilities as new CVEs are disclosed, and stale images silently rot.

Limitations

Vulnerability counts include issues that may be unreachable or unexploitable in the running container, so raw numbers overstate real risk without reachability analysis. Scanner databases differ, producing different counts for the same image, which limits cross-tool comparison. Severity ratings are generic and may not match your context. Unfixable vulnerabilities can persist regardless of effort, frustrating attempts to reach zero. The metric measures known vulnerabilities only, missing zero-days and misconfigurations. It is best combined with runtime context, reachability, and configuration scanning rather than used as a sole security gate.