Skip to content

PATTERN Cited by 1 source

Runtime Vulnerability Prioritization

What it is

Runtime vulnerability prioritization is the pattern of augmenting each vulnerability finding from a registry / image scanner with real-time runtime context — which workloads are currently running the vulnerable image, across how many pods, how recently used — so that remediation priority is driven by actual production exposure, not by which images happen to exist in a registry.

The problem this fixes

A naive registry-wide vulnerability scanner reports every CVE found in every image in the registry. For organizations of realistic size this is:

  • Tens of thousands of findings (10K+ CVEs across 100s of images is common).
  • No priority signal — severity scoring (CVSS) tells you how bad the CVE could be in general, not whether it's exploitable in your environment.
  • A large fraction of findings are unreachable — they're in images no one runs, in abandoned projects, or in base images deprecated from active use.
  • High-severity CVEs in unused images outrank low-severity ones in production base images — exactly the opposite of real risk.

The shape

For each vulnerability finding, record and expose:

Augmentation What it reveals
Running cluster ARNs Is this image deployed anywhere?
Number of pods running the image How big is the blast-radius?
Last in-use date per finding Is this a live dependency or a relic?

Then:

  1. Prioritize remediation by (severity × running-pod-count × recency).
  2. Deprioritize findings in images with zero running workloads.
  3. Surface the most-deployed CVEs as a top-of-list dashboard item.

Canonical instance

Amazon Inspector's "map Amazon ECR images to running containers" capability is the canonical AWS production realisation. Inspector crosses the static ECR scan with the live EKS cluster state, annotating each finding with cluster ARNs, pod count, and last-use date per finding. Generali uses this as the prioritization substrate for their EKS vulnerability- remediation workflow.

From the source (Generali, 2026-03-23):

"Prioritize remediation efforts based on actual container usage patterns rather than repository events alone, and comprehensive vulnerability management across container images."

Why this is structural, not tooling

The key insight: the fix isn't a better CVE scorer. The fix is crossing the scanner's world (registry images) with an orthogonal data source (running workloads). The two sources live in different services:

  • Scanner knows: "image foo:v1.2 has CVE-X."
  • Orchestrator knows: "127 pods are running foo:v1.2 across 12 clusters; last deployed 4 hours ago."

Neither side alone can prioritize. The augmentation is the load- bearing move.

This makes the pattern structurally a sibling of telemetry-based resource discovery (AWS DevOps Agent) — both fuse a static inventory source with a live runtime source into a single higher-signal view.

Caveats

  • Image-tag churn can desynchronise the mapping. If the scanner looks at :v1.2 but workloads run :latest, the mapping may be empty despite real production exposure. Digest-pinned image references are the robust version.
  • Short-lived workloads (Jobs, batch pods) may not reflect in a snapshot. The mapping is correct at observation time; a cron- batch vulnerability may hide between scans.
  • Does not address supply-chain or build-time CVE introduction risk — that's upstream of the pattern.

Seen in

Last updated · 200 distilled / 1,178 read