The vulnerability management playbook most of us learned was built for persistent infrastructure. A scanner sweeps your hosts on a scheduled cadence, finds a CVE, creates a ticket, an engineer patches the host, the next scan confirms closure. The asset exists the whole time. It has a persistent IP, a stable hostname, a configuration state that reflects cumulative changes. The scanner and the remediation workflow share an implicit assumption: the thing we found a problem on is still there.
That assumption breaks in ephemeral environments. Consider a Kubernetes-based microservice deployment where application pods recycle every few hours due to autoscaling events, rolling updates, and spot instance interruptions. A network-based scanner that detects a vulnerable OpenSSL version on a running container at 2am has found something that may no longer exist by 9am when a human reviews the finding. The ticket gets created. Engineering looks at the target hostname. It resolves to nothing. The finding gets marked as a false positive or closed without remediation. Meanwhile, every new pod spawned from the same base image ships the same vulnerable library, scanned or not.
This is the core problem with ephemeral infrastructure: the unit of risk is the image, not the running instance. Traditional scan-then-ticket workflows address the instance. Fixing ephemeral infrastructure means addressing the artifact.
Why Traditional Workflows Break
The mismatch between scanner cadence and instance lifetime is the most visible failure mode, but there are three others worth naming explicitly.
Asset inventory churn: Most vulnerability management platforms maintain an asset inventory that links findings to persistent identifiers — hostnames, IP addresses, agent install IDs. In ephemeral environments, these identifiers are transient. An instance that was critical to production at 8am may have been terminated and replaced by a new instance with a different IP by noon. If your asset inventory doesn't reconcile against dynamic infrastructure metadata (cloud provider instance tags, container image digests, deployment labels), the linkage between findings and business-context criticality breaks. You lose the asset criticality signal at exactly the point where ephemeral instances are handling production traffic.
Patch-the-running-instance fallacy: In persistent infrastructure, remediation means updating the installed software on the host. In containerized environments, doing this on a running container is operationally wrong — the fix won't persist through the next pod restart, and it puts the running container out of sync with its source image. If an engineer SSHes into a running pod and installs a patched package, the vulnerability scanner may confirm closure (the running instance no longer shows the CVE), but the next pod launched from the unmodified image will re-introduce it. The remediation happened at the wrong layer.
False positive inflation from scan timing: When a scanner's detection event and the asset's lifecycle don't align, the finding data becomes unreliable. A container that exists for 4 hours may be scanned once (or not at all), and findings that can't be confirmed across multiple scans get flagged as intermittent or low-confidence. Teams learn to discount these findings, which is rational at the instance level but wrong at the image level.
Shifting Left: The Image as the Remediation Unit
The correct frame for ephemeral infrastructure is: vulnerability assessment happens on the image build artifact, not on running instances. This shifts the detection point from production runtime to the CI/CD pipeline, before anything reaches a running environment.
Container image scanning integrated into the build pipeline checks the image layers against a CVE database at build time. The output is a list of vulnerable packages in the image — not in a running container, but in the artifact itself. If a base image (e.g., a Debian or Alpine layer pinned at a specific digest) contains a known CVE, every container spawned from that image is affected. The remediation action is updating the base image reference or adding a package update layer — both of which are committed to source control and affect every future deployment.
The practical implications for vulnerability management workflows:
Findings should be linked to image digests, not running instance identifiers. A finding on `sha256:abc123...` (the image digest) is persistent and reproducible. A finding on an EC2 instance ID or pod IP is not. When your asset inventory tracks image digests and their deployment history — which services are running which image versions, which images are currently in production — the finding-to-asset linkage becomes durable.
Remediation tickets should reference the source image and the affected registry tag, not a specific running asset. The engineering action is a pull request that updates the image dependency, not a host-level patch job.
Scoring Risk on Short-Lived Assets
Asset criticality scoring in ephemeral environments needs to be tied to service identity, not instance identity. An individual pod in a payment processing service is ephemeral, but the service itself is persistent and high-criticality. The criticality tier should be assigned at the service or workload level, then propagated to any assets running under that workload.
In practice, this means enriching your vulnerability management data with cloud provider metadata: Kubernetes namespace, deployment name, service account, labels like `env=production` vs `env=staging`. A finding on an image running in a production namespace with a `tier: critical` label should carry a different prioritization weight than the same image running in a development namespace — even though the underlying CVE is identical.
EPSS and CVSS still apply at the image/CVE level. The environmental modifier — the part of CVSS that accounts for deployment context and compensating controls — becomes the layer where ephemeral infrastructure characteristics get encoded. A CVE in a container that has no outbound network access, runs in a read-only filesystem, and is isolated by a network policy to a specific pod-to-pod communication pattern has a meaningfully different actual exploitability than the same CVE in a container running with host network access in a production cluster.
Handling the Patching Lag Problem
One of the trickier operational realities of container-based remediation is patch availability lag. A CVE is disclosed, NVD publishes an entry, your image scanner picks it up, and you create a remediation ticket. But the upstream base image maintainer may not have published a patched version yet. For Alpine-based images, patches tend to arrive quickly. For some commercial base images, the cycle is slower. In the meantime, what do you do?
The most defensible approach in this window: compensating controls documentation in the ticket itself. If the CVE requires remote code execution via a network service and your container doesn't expose that service, document that control explicitly. If a WAF rule or network policy blocks the attack vector, note it. This is the same logic as accepted-risk workflows in traditional VM, applied to an ephemeral context where "wait for the patch" may be the only available action.
What you should not do: close or deprioritize the finding just because the instance that triggered detection no longer exists. The image it came from is still being deployed.
What Traditional VM Tools Get Wrong for This Use Case
We're not saying traditional VM platforms can't work in cloud environments — they've all added container scanning capabilities and most support agent deployment into pods. But the design center of most VM platforms is a persistent-host model: they were built to track findings through a lifecycle on a specific asset that exists over weeks or months.
Where this creates friction: finding deduplication logic that expects an asset to persist, MTTR calculation that measures from first-seen on a specific host (not from first-seen of a CVE across all instances of an image), and reporting that presents findings as "open on X hosts" rather than "present in Y images that are deployed to Z services."
The instrumentation we've found most useful treats image digest as the primary finding key, aggregates across running instances of the same digest, and scores risk at the service level rather than the instance level. When a new image digest is deployed that eliminates a CVE, findings against the old digest are closed — not because a scanner confirmed closure on a specific host, but because the artifact containing the vulnerability is no longer deployed.
Ephemeral infrastructure is increasingly the default for cloud-native teams, not the exception. Vulnerability management that doesn't account for it produces a finding dataset that's partly fiction — things that appear open because a long-terminated container was scanned once, things that appear closed because the specific instance that was ticketed no longer exists, and real risks that propagate silently through every new deployment because the image was never updated. Getting the unit of analysis right — the image, not the instance — is the prerequisite for everything else to work.