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 vulnerable code had been present all along; it simply was not listed in the vulnerability feed when the original scan ran. That made me realize the scan was only reporting what was publicly known at that moment, not proving the image was safe.
There is a similar issue with image tags. A tag may represent an application version without saying when the image was built. An image that has been sitting for months can still contain outdated packages even if the tag appears unchanged.
Beyond rebuilding more often and tracking base images that receive upstream updates, what is the proper operational model? Should a clean CI scan be treated only as a point-in-time snapshot, with deployed images rescanned continuously?
5 Answers
This is essentially image vulnerability drift: the artifact stays the same while the security knowledge around it changes. A mature process connects SBOMs, vulnerability-feed updates, automated rebuilds, testing, and redeployment. CI scanning is still useful for preventing known issues from shipping, but it needs a separate continuous process for images already in registries and production.
A vulnerability scanner can only detect issues that are known to its database. It cannot identify vulnerabilities that have not been disclosed yet, so a clean result should never be treated as proof that the image is safe. The practical response is to rescan images after new vulnerability data is published, not just when they are built.
Treat image tags as human-friendly labels, not build or freshness metadata. Pin deployments to digests and add labels such as build timestamp, source revision, base-image version, and SBOM identifier. That makes it clear exactly what was built and lets you reproduce or replace it when its components develop new findings.
Shift-left scanning is only one layer. Keep it, but add periodic registry scans and runtime detection so a newly disclosed issue in a running image generates an actionable alert. Whether you automatically rebuild and deploy depends on the vulnerability and your testing, but discovering the issue should not wait for the application to be changed.
Scan the images that are actually deployed on a schedule, using their immutable digests rather than only scanning new CI builds. Alert when a newly published critical affects an existing digest. Registry scans and runtime monitoring can both help, and an admission or deployment policy can prevent newly vulnerable images from being rolled out.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures