Container Image Vulnerability Calculator

Image risk = 0.2 × (critical × 10 + high × 5 + medium × 2 + low × 0.5) per image, clamped to 0–100, where critical and high include CVEs inherited from the base image. A container image inherits every vulnerability in its base layers, so one unpatched base image multiplies across every image built on it. Separating inherited from application-layer CVEs turns a fleet of thousands of findings into two numbers: the ones a base image bump fixes and the ones that need an actual code or dependency change.

Scanner output looks like an unwinnable backlog until you notice that the same six base-image criticals account for two thirds of it, and one rebuild closes them everywhere at once.

This calculator takes 9 inputs: Images in the registry, Images built on the shared base image, Critical CVEs in the base image, High CVEs in the base image, Critical CVEs added by application layers, High CVEs added by application layers, Medium CVEs per image, Low CVEs per image, CVEs with a fix available. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

No. Prioritise by fixability, reachability and severity in that order. A critical CVE in a library your code never loads is not urgent; a high CVE in your HTTP parser is. Distroless or minimal base images reduce the count dramatically simply by removing packages you never used.

Weekly, on a schedule, with no human in the loop. CVE age is the metric that matters, and a scheduled rebuild keeps it bounded automatically. Chasing individual advisories with manual rebuilds always loses to the rate at which advisories are published.