When teams scan only one tag, they can miss secrets embedded in older builds, release branches, or alternate versions that remain publicly accessible. Tags are version labels, not security boundaries, so a repository may hold many distinct images with different contents. The control gap is simple: one clean tag does not prove the repository is free of leaked credentials.
Why Scanning One Tag Breaks the Security Assumption
Scanning a single Docker tag only answers whether one specific image variant is clean at that moment. It does not prove the repository is clean, because tags can point to different layers, different build outputs, and different historical contents. In practice, older release tags, rebuilds, and alternate tags often carry the exact secrets teams thought they had removed.
That matters because container registries are usually treated as distribution systems, not security boundaries. If a secret was baked into one image and later removed from a newer tag, the older tag may still be pullable, cached, or mirrored elsewhere. GitGuardian’s State of Secrets Sprawl 2025 reports around 100,000 valid secrets found in public Docker images, with ENV instructions alone accounting for 65% of container secret leaks, which shows how often secrets survive inside image history rather than disappearing with the latest build.
In practice, many teams discover the leak only after assuming one clean tag was enough, not after validating every tag that the repository still exposes.
How Tag-by-Tag Scanning Changes the Result
Docker tags are references, not guarantees of equivalence. A repository can hold many tags for the same nominal application, and each tag may resolve to a different manifest, different filesystem contents, or different environment metadata. If scanning only checks the newest release tag, it can miss secrets in a maintenance branch, a patched rebuild, a staging image, or an abandoned version that is still publicly available.
The practical failure is usually one of coverage, not tooling accuracy. The scanner may work perfectly on the image it sees, but the process fails to enumerate all tags and therefore fails to inspect all artifacts that attackers or third parties can still retrieve. That is especially important when the image has been rebuilt multiple times, because secrets removed from the latest Dockerfile may remain present in older layers or in variants created before the fix.
A useful way to think about the control is that the unit of assurance is the repository’s full tagged surface, not a single tag. Teams need tag discovery, image selection logic, and consistent scan rules so that the scope is explicit. Otherwise, a clean result on one tag can create false confidence while another tag continues to expose credentials, API keys, or tokens. The operational question is not just whether an image scanned clean, but whether every live tag that matters was actually included in the scan set.
- Enumerate all discoverable tags before choosing scan targets.
- Include release, rollback, maintenance, and legacy tags in the same policy scope.
- Retain enough scan evidence to show which tags were inspected and when.
Docker image scanning guidance from the OWASP Non-Human Identity Top 10 is relevant here because leaked secrets in images are still machine credentials that can be abused long after the build completes. These controls tend to break down when teams scan only the tag they deploy, because the registry often contains older, still-pullable tags with different embedded secrets.
Common Failure Modes and Boundary Cases
Tighter tag coverage often increases scan volume, so teams have to balance completeness against registry size, build frequency, and prioritisation. The tradeoff is worth stating clearly: scanning every tag is more expensive, but selective scanning creates blind spots that are hard to justify after a leak.
Some repositories also contain tags that are functionally redundant, such as multiple tags pointing to the same manifest. Current guidance suggests deduplication is useful, but only after the team has verified equivalence rather than assuming it. The harder edge case is mutable tags, where a label can move to a new image over time. In that environment, a one-time clean result is weaker than a repeatable inventory of tag-to-digest relationships.
Another common mistake is treating private registries as lower risk. Private access reduces exposure, but it does not eliminate the consequences of embedded secrets if an internal user, compromised pipeline, or mirrored environment can still pull the image. The better boundary is whether the tag is still reachable, not whether it is formally public.
Where the process breaks down most often is with legacy repositories that have accumulated many tags over time and no clear retirement policy, because no one can confidently say which image versions remain live.
Risk and Threat Considerations
The material risk is credential exposure through incomplete image coverage. A single scanned tag can look clean while other tags in the same repository still expose secrets, which leaves reusable credentials available to insiders, attackers, or downstream systems that can still pull the image.
Failure mechanism: The weakness is incomplete enumeration. If a secret was committed into one build, it can persist in older tags, alternate releases, or cached copies even after the current tag is fixed. Attackers do not need to defeat the scan; they only need to discover an unscanned tag with the same repository lineage.
Impact: The likely consequence is credential reuse, unauthorized access, and delayed incident response. A missed tag can extend the lifetime of a leaked token or key, making rotation and revocation less effective because the exposed artifact remains available after the team believes remediation is complete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 3 — Data Protection | Image tags may hide embedded secrets that data protection controls should detect and limit. |
| 6 — Access Control Management | Leaked image secrets can grant unauthorized access if older tags remain pullable. | |
| Recommendation — Scan all tagged images and block builds that contain exposed secrets or sensitive credentials. Revoke and replace credentials found in any tagged image before treating the repository as clean. | ||
| NIST CSF 2.0 | DE.CM-08 — Vulnerability Scanning | Complete image scanning requires coverage across all repository tags, not one sampled tag. |
| Recommendation — Expand scanning coverage to every live tag and document the scope of each inspection. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Embedded secrets in image tags are exposed credentials that adversaries can steal and reuse. |
| Recommendation — Hunt for credentials in all image variants and rotate any secret recovered from a tag. | ||
Practitioner Guidance
What to prioritise: Treat tag enumeration as part of the security control, not a housekeeping task. If the repository can still present multiple tags, the scan scope should be defined in terms of all reachable tags and tied to the image digest inventory.
What to verify: Confirm that the scan process records which tags were discovered, which were deduplicated by digest, and which were actually analysed. A clean report without that evidence should be treated as incomplete rather than reassuring.
Decision rule: If a repository contains release history, rollback tags, or long-lived maintenance labels, scan them all before declaring the repository free of secrets. If tag coverage cannot be proven, treat the result as partial coverage and rotate any credential found in the image path.
Practitioner takeaway: The real control is not “scan the image” but “prove the full tagged surface was inspected,” because attackers and remediation failures both exploit the gap between one clean tag and the rest of the repository.
Related resources from NHI Mgmt Group
- What breaks when AI agents can chain tools through MCP without tight policy controls?
- What breaks when a Kubernetes-hosted MCP server is exposed through a tunnel without scoped authorization?
- What breaks when authentication risk decisions are not threaded through every step of a multi stage sign up flow?
- What breaks when a GitHub Action is hijacked through a tag force-push in CI/CD workflows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
