An unchanged image shows new vulnerabilities because the knowledge about it changed. A new advisory was published, a severity or fix status was updated, or the scanner learned to read more packages. The bytes in the image are the same. Your exposure may not have changed either, but you now know more.
The image is fixed, the data is not
A container image is identified by a content digest, a hash of its manifest. Pull the same digest tomorrow and you get the same layers. The Kubernetes documentation on images describes the digest as a hash algorithm plus a hash value, and that is why a digest is a stable thing to record a scan against.
The vulnerability side has no such stability. Advisories arrive daily, existing records are edited, and fix versions appear weeks after the first disclosure. So a scan result is really a statement of the form "this digest, checked against this data, on this date". Change the data and the statement changes.
The five usual causes
| Cause | What changed | What to do |
|---|---|---|
| New advisory | A flaw in a package you already ship was published | Triage like any new finding |
| Fix became available | A package now has a patched version | The finding becomes actionable, plan a rebuild |
| Severity or scoring edit | The record was rescored | Check whether it crosses your policy line |
| Exploitation evidence | The flaw was added to a known exploited list | Raise priority, see below |
| Scanner update | New parsers or new data sources | Compare tool versions between scans |
The exploitation case deserves attention. The CISA Known Exploited Vulnerabilities Catalog records a date added for each entry, and an old library in an old image can land on that list long after you shipped it. That is an event, not noise.
How to find out which cause it was
- Compare the digest in both scan records. If it differs, the image changed and this is a different question.
- Compare the vulnerability data date or scanner version stored with each result. Good tooling keeps both.
- Diff the finding lists. New rows for packages that were already present point to advisory data. New rows for packages that were never listed point to a scanner change.
- Check for each new finding whether a fixed version exists.
If your tooling does not record what data a scan used, you cannot answer this question later. That is worth fixing before an auditor asks.
What to do with the answer
Do not treat the new findings as a regression in the image or in your team. Route them through the same triage as any other finding. If a fix exists in the base image, rebuild. If the vulnerable code is not reachable from your application, record that decision with an expiry date.
For images already deployed, remember that a rebuild does nothing until the workload is redeployed. Running pods keep the layers they pulled.
Stop being surprised
Two habits remove most of the surprise. First, rescan stored digests on a schedule, not only when someone pushes. Second, alert on change in findings for a digest, not only on the first scan. A report that says "nothing changed since last week" is a useful report.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the demo and watch how a monitored item raises findings later without any new commit.
Where Safeguard fits
Safeguard keeps SBOM and dependency scan results per image and re-evaluates them as advisory data changes, so a new finding on an old digest is visible with its cause. You can try a free scan.
Quick check
Is a new finding on an old image a sign the image was tampered with?
No. The digest tells you whether the content changed. If the digest matches your earlier record, the cause is new or updated vulnerability data.
Should I rebuild every time a new finding appears?
Only when a fix exists and the finding matters for your use of the package. Otherwise record a decision with an expiry date and revisit.
Sources
Last reviewed: 19 October 2026.
