Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
To prioritise container vulnerabilities, combine four signals: whether the CVE is on the CISA Known Exploited Vulnerabilities catalogue, its FIRST EPSS exploitation probability, whether the vulnerable code is reachable in the image, and whether a running, exposed workload uses that image. Severity alone ranks every image the same way; these signals rank them by what an attacker would use.
Scan a registry of a few hundred images and you will get thousands of findings, a large share marked high or critical. Nobody fixes that list from the top. This guide sets out the signals that actually separate urgent container findings from background noise, the order to apply them in, and the mistakes that make a prioritised list untrustworthy.
The worked example is a platform team responsible for a shared registry and a set of Kubernetes clusters. Their base image carries a critical OpenSSL advisory, a dozen services build on it, and every service team is asking whether this week’s sprint has to change.
CVSS severity describes the flaw, not your container
The Common Vulnerability Scoring System, maintained by FIRST, scores the technical severity of a vulnerability in the abstract. A critical score says the flaw would be serious if exploited. It does not say whether anyone is exploiting it, whether your image ever loads the vulnerable library, or whether the container runs anywhere an attacker can reach.
For the platform team, every one of the dozen services inherits the same critical score from the base image. Sorting by CVSS puts all twelve at the top together and gives the service teams no way to choose. The general case against severity-only ranking is made in risk-based vulnerability management; container findings add the image and workload dimensions on top.
CISA KEV tells you a vulnerability is already exploited
The Known Exploited Vulnerabilities catalogue, published by CISA, lists vulnerabilities with reliable evidence of exploitation in the wild. US federal civilian agencies must remediate listed vulnerabilities by set deadlines under Binding Operational Directive 22-01, and many private organisations use the catalogue as a priority floor for the same reason: it is evidence, not prediction.
A KEV listing should move a container finding to the top tier regardless of its CVSS score, provided the image is running. The catalogue is small relative to all published CVEs, which is what makes it useful as a filter. If the OpenSSL advisory in the platform team’s base image is on the catalogue, the conversation with service teams is about how fast, not whether.
EPSS estimates which vulnerabilities are likely to be exploited next
The Exploit Prediction Scoring System, also from FIRST, estimates the probability that a vulnerability will see exploitation activity in the next thirty days. Scores range from 0 to 1, are refreshed daily, and come with a percentile that places each CVE against all others. EPSS covers the long tail that KEV does not yet list.
Use EPSS as a ranking signal within tiers rather than a hard threshold. A vulnerability with a high EPSS score and no KEV listing deserves attention before a critical-severity CVE with a negligible score. Recheck it regularly too, because scores move when public exploit code appears.
Reachability and running workloads decide which images matter
Exploitation data is about the CVE. Two further questions are about your container. First, is the vulnerable package actually used: an OS library pulled in by the base image may never be loaded by a statically compiled service, while a vulnerable function called from a request handler is fully in play. Second, is the image running, and where? An image sitting in the registry with no workload is inventory; the same image behind a public ingress is exposure.
Answering the second question requires binding images to workloads by digest, not tag, as explained in container images to workloads: bind by digest. For the platform team, that binding shows that only four of the twelve services run the vulnerable digest in production, and two of those are internet-facing.
Combine the signals into tiers your teams can act on
| Tier | Condition | Expected response |
|---|---|---|
| 1 | KEV listed, running, exposed | Fix or mitigate now |
| 2 | KEV listed or high EPSS, running, reachable | Fix this sprint |
| 3 | Running, reachable, no exploitation signal | Fix within the normal timeline |
| 4 | Not running, or not reachable | Fix through base-image refresh |
Tiers only work if every finding shows why it landed where it did. A service team that disagrees with a tier should be able to see the KEV listing, the EPSS score, the reachability verdict and the workload binding, and challenge the specific input that is wrong. Low tiers are not dismissals: tier 4 findings stay visible and are cleared in bulk by rebuilding on a patched base image, which is the subject of container image scanning: layers and base images.
Key takeaways
- Treat a CISA KEV listing on a running image as a priority floor, whatever the CVSS score says.
- Use EPSS to rank within tiers and recheck it regularly, because scores change as exploits appear.
- Bind images to workloads by digest before ranking, so registry-only images stop competing with exposed services.
- Show the inputs behind every tier so service teams can challenge the evidence rather than the ranking.
How SecurityVault approaches this
SecurityVault uses CISA KEV and FIRST EPSS alongside available reachability and exposure context to help prioritise findings. Digest-based workload associations help identify known running images and explain which services need attention. A KEV listing is evidence of exploitation somewhere, not evidence that your service has been compromised; an EPSS score is not a probability of compromise for your organisation.
Use several known image findings to inspect how different signals affect their order. Include a known-exploited vulnerability with unknown reachability, an exposed workload with no exploitation signal and an image that has not been deployed. Ask the service owner to review the evidence and challenge any incorrect association. The desired result is an explainable work queue whose uncertainty remains visible. Agree remediation windows through your own risk process rather than treating the illustrative tiers in this article as universal deadlines for every organisation.
Explore Vulnerability management or talk to our team about an evaluation with your engineering, security and compliance stakeholders.