Image version diffing turns scan data into release validation

At a glance

What this is: This is a container image version-diff workflow that compares two releases by digest to show which vulnerabilities were fixed, introduced, or persisted.

Why it matters: It matters because container security teams need release-level evidence, not just snapshot scans, to judge whether a build actually reduced risk or merely reshuffled it.

Context

Container image comparison is a governance problem as much as a technical one: teams need to know whether a new build genuinely reduced exposure or simply changed the inventory of known issues. Tag names are easy to read, but the digest is the real identity of the image, which is why version-to-version analysis has to start there.

That distinction matters for container image security because vulnerability management in containers is only useful when it can distinguish inherited issues from newly introduced ones and from risks that persisted across releases. In practice, this is the difference between a point-in-time scan and evidence that can support release decisions.

Key questions

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. That gives teams a release-level view of net risk change and avoids mistaking a new scan count for progress. The most useful control question is whether known exposure went down in the build that will actually ship.

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. That matters because teams make decisions about remediated risk, newly introduced defects and vulnerabilities that survived the update. Without the diff, a programme can report volume without showing whether engineering actually improved the image.

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. If a fix is available and the issue still persists across versions, teams should treat it as a delivery and governance failure, not just another scan result.

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.

Technical breakdown

Why image tags are not enough for release comparison

A container image tag is a mutable label, while a digest is the immutable content address that identifies the exact image bytes. If a team compares tags alone, it risks treating two different artifacts as the same release. The practical workflow is to resolve each tag to its digest first, then compare the vulnerability sets attached to each digest. That lets security teams ask whether a change in packages, dependencies or base layers altered the exposure profile in a meaningful way. See the Container Image Security Guide. See the Container Image Security Guide.

Practical implication: Use digests, not tags, as the comparison unit for release validation and audit evidence.

How vulnerability set operations expose fixed, introduced and persisting risk

Once each digest is known, the vulnerability data can be treated as sets of identifiers. The difference between the two sets shows what was fixed in the newer image and what was introduced by the new build. The intersection shows what persisted across versions, which is often the most operationally important result because it reveals open risk that survived the change. In container programmes, this is a stronger governance signal than a raw vulnerability count because it ties findings directly to a specific release transition. See the Container Security Guide.

Practical implication: Track fixed, introduced and persisting vulnerabilities for each build so release gates can judge net risk change.

Why persisting vulnerabilities deserve separate treatment

Persisting vulnerabilities are not just leftovers, they are evidence that a build process did not eliminate known exposure. When a persisted issue also has a fix available, the gap is no longer discovery but execution: the team knows the defect exists and knows a remediation path exists as well. That makes persisting findings especially useful for development and release governance because they can feed directly into the next iteration rather than waiting for a future scan cycle. This is also where container security becomes lifecycle management rather than one-off triage. See the Container Security Buyer's Guide.

Practical implication: Escalate persisting findings with available fixes into the next release cycle instead of treating them as static scan noise.

Breaches seen in the wild

• Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
• Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Digest-based comparison should be treated as the image identity control, not a convenience feature. Tags are operationally useful but too mutable to serve as the basis for trustworthy comparison. When teams anchor comparison to digest identity, they are effectively asserting which artifact was assessed, which is essential for auditability, reproducibility and repeatable remediation decisions. The practitioner conclusion is to make digest resolution part of the standard release workflow.

Persisting fixes are the strongest signal of whether a container programme is maturing. If vulnerabilities survive multiple versions even when fixes exist, the issue is not lack of visibility but weak follow-through in the delivery process. That is where container governance intersects with container security: the control objective is to reduce the gap between known exposure and shipped remediation. The practitioner conclusion is to measure how quickly known issues disappear across versions, not just how many are found.

Release-risk diffing should replace raw vulnerability tallies as the primary reportable metric. Counts alone can make a build look better or worse without explaining whether the change helped. A diff-based model tells the story practitioners actually need: what was removed, what was added, and what remains unresolved. The practitioner conclusion is to report net risk movement at release boundaries, not scan totals in isolation.

Read next: Container Image Security Guide

What this signals

Release validation becomes materially stronger when it is built around artifact identity. Container programmes that anchor comparison on digests rather than tags can explain security change in terms developers and auditors both understand. That shift turns vulnerability management into a release governance control, not just a scanning activity.

Diff-based reporting is the right operational language for container risk. Teams do not need another count of open vulnerabilities as much as they need to know whether the latest build fixed anything, introduced anything, or left critical exposure unchanged. The programme signal is clear: measure movement across versions, not just inventory at a point in time.

For practitioners

• 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.
• Use severity filters for release gates Apply a severity threshold when the goal is compliance or go-live approval so the diff output highlights the findings that actually block release.

Key takeaways

• Container image security becomes more actionable when teams compare releases by digest instead of relying on tags alone.
• A version diff exposes whether a new build fixed vulnerabilities, introduced new ones, or left risks unchanged.
• Persisting findings with available fixes should flow directly into the next release cycle, not sit in a static scan report.

Related NHI Mgmt Group resources: Container Image Security Guide · Container Security Guide · Container Security Buyer's Guide · Zero-Day and Exploited Vulnerabilities Guide

Key terms

• Container Digest: A container digest is the immutable cryptographic identifier for a specific image build. Unlike a tag, which can be moved or reused, the digest points to the exact artifact that was scanned, compared or deployed, making it the correct basis for repeatable security analysis and release governance.
• Vulnerability Diff: A vulnerability diff is the comparison of two scan results to show what was removed, what was added and what remains in both versions. It turns vulnerability management from a snapshot exercise into a change-control signal that can support release decisions, remediation prioritisation and audit evidence.
• Persisting Vulnerability: A persisting vulnerability is a finding that appears in both the older and newer version of an image. In practice, it signals unresolved exposure across a release boundary, and if a fix exists, it usually indicates a remediation or delivery gap rather than a discovery gap.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.