We scan container images in CI and block releases when critical vulnerabilities are found. An image passed the scan and was deployed, but about three weeks later the exact same image—never rebuilt or modified—was flagged for a critical vulnerability in a library inherited from its base image. The scanner was not wrong; the vulnerable code had been present all along, and the vulnerability was only added to the public database after the original scan.
That made me realize I had been treating a clean scan as proof that an image was safe, when it really only showed that no known issues were detected at that point in time. Image tags add another complication: an application version tag says little about when the image was built or whether its underlying packages have received newer fixes. An unchanged tag can conceal stale dependencies for months.
Beyond rebuilding more often and following base images that track upstream fixes closely, what is the accepted operational approach? Do teams treat CI scanning strictly as a point-in-time gate and continuously rescan registry contents and deployed images afterward? I'm interested in how others handle newly disclosed vulnerabilities, image metadata, digest pinning, and automated rebuild or redeployment workflows.
5 Answers
A clean scan can only mean that no currently known vulnerability matched the image at that moment. It can never account for undiscovered bugs or vulnerabilities that have not been published yet. That limitation is fundamental, so the scan should be treated as a snapshot rather than a safety guarantee.
Shift-left scanning is valuable for preventing known issues from entering production, but it is only one part of the model. Pair it with continuous registry and runtime visibility, clear ownership of deployed images, and a documented response process for newly disclosed critical vulnerabilities.
The practical fix is to continuously rescan images that already exist in your registry and, more importantly, the digests currently deployed. Schedule scans independently of CI and alert when a newly published critical affects an existing image. Runtime monitoring or admission controls can add another layer, but they do not replace regularly checking what is already running.
Teams often call this image or CVE rot: an image that was acceptable when released becomes risky as new advisories appear. A mature workflow links deployed-image SBOMs to automated rebuild and redeployment pipelines. When a new issue is found, the system can rebuild from a pinned, reproducible base, rerun tests, and roll out the replacement automatically when remediation does not require a configuration or application decision.
Faster rebuilds help, but the key is triggering them from newly discovered vulnerabilities in deployed artifacts—not only from source-code changes. Some findings still need a human decision, especially when the fix involves configuration or compatibility risk.
Use immutable digests for deployments and attach labels or SBOM metadata containing details such as the build timestamp, source revision, base-image digest, and package versions. A tag can be useful for humans, but it should not be the source of truth for identifying exactly what was built or deployed.
This is why build-time scanning alone is not enough. The image stays unchanged while the vulnerability database changes, so the deployed inventory has to be checked again.