Topic starter
25/10/2026 10:59 am
TL;DR: Comparing container image versions by digest and vulnerability set separates fixed, introduced and persisting issues, with Anchore in the middle of the finding. Release validation works better when teams track what changed between builds instead of treating a single scan count as progress.
Editorial analysis by NHI Mgmt Group, based on content published by Anchore: “Comparing Vulnerabilities Across Image Versions via the Anchore Enterprise API”.
Key questions
Q: Why do container scans need version-to-version comparison instead of a single snapshot?
A: A snapshot only shows current exposure, while version-to-version comparison shows what changed between releases.
Q: What do persisting vulnerabilities tell practitioners about their release process?
A: Persisting vulnerabilities show that a release did not eliminate issues that were already known, which usually means the problem is in remediation follow-through rather than detection.
Q: How should teams validate whether a new container image actually reduced risk?
A: Compare the new image against the previous release using digests, not tags, and separate findings into fixed, introduced and persisting sets.
Practitioner guidance
- Resolve image tags to digests before comparison Make digest resolution a required step in release validation so every comparison is tied to an immutable artifact rather than a mutable tag.
- Compare vulnerability sets across consecutive builds Use set differences to identify what was fixed and introduced, then use intersections to isolate findings that persisted through the release.
- Escalate persisted vulnerabilities with available fixes Route findings that remain present across versions into the next remediation cycle, especially when the newer image still exposes a fixable package.
Bottom line: Container image security becomes more actionable when teams compare releases by digest instead of relying on tags alone.
Glossary terms: Container Digest, Vulnerability Diff, Persisting Vulnerability
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:16 pm
Version diffing is the governance layer container teams are missing. A single scan tells you what is present now, but it does not tell you whether the latest build improved or degraded the security posture relative to the last one. Release validation needs that delta view because teams make risk decisions about change, not about isolated snapshots. The practitioner conclusion is that vulnerability management becomes materially more useful when it is tied to build-to-build change analysis.
A question worth separating out:
Q: Should security teams report raw vulnerability counts or release diffs?
A: Release diffs are more useful because they show whether a build improved the security posture, introduced new exposure or left known problems untouched. Raw counts can be misleading when a new image changes package composition. For governance, the better question is how much risk moved between versions, not how many findings exist today.
👉 Read our full editorial: Image version diffing turns scan data into release validation
This post was modified 7 days ago by NHI Mgmt Group