Security teams should scan each image tag and each platform variant, because secrets can exist in any layer of any build. A practical workflow is to enumerate all manifests, pull each digest, and inspect layers for embedded credentials. Single-architecture scans are often enough for routine checks, but multi-architecture repositories need full coverage to avoid blind spots.
Why Scanning Every Tag and Architecture Matters
Docker image scanning is only reliable when it covers the exact artefact a runtime might pull. Tags can point to different digests over time, and multi-architecture manifests can hide platform-specific layers that never appear in a single scan of the repository root. If a secret lands in one build variant, a partial scan can miss it even when the image looks clean elsewhere. That gap matters because leaked credentials in containers are often immediately usable, especially when they are embedded in environment instructions or build layers.
For teams dealing with container registries, the real question is not whether a secret exists somewhere in the repository, but whether every published variant has been inspected before it is trusted. GitGuardian’s State of Secrets Sprawl 2025 reported around 100,000 valid secrets in public Docker images, with ENV instructions alone accounting for 65% of all container secret leaks, which shows how often credentials are baked into artefacts rather than injected safely at runtime.
In practice, teams usually discover the blind spot only after a new tag, a rebuild, or a platform-specific pull has already shipped.
How It Works in Practice
A useful workflow starts by enumerating every manifest associated with the repository, then resolving each tag to its current digest and each digest to the platform-specific image variants it exposes. That matters because a tag is just a moving pointer, while the digest is the immutable object that should be scanned and recorded. For multi-architecture repositories, the scanner must inspect each architecture separately, not just the manifest list, because the layers and injected build artefacts can differ by platform.
Teams should look for secrets in places that commonly survive into the final image: environment declarations, copied config files, package metadata, shell history left in layers, and build arguments that were unintentionally preserved. A scanner that only checks file names or the top layer can miss credentials introduced earlier in the build chain. This is why image scanning should be paired with deterministic build practices: the more reproducible the build, the easier it is to compare what should exist with what actually exists.
For operational use, the control should be attached to CI/CD and registry workflows rather than treated as a one-time audit. Scan on pull, rescan on tag change, and rescan whenever a new platform variant is added. When a secret is found, treat the result as both a leakage and an attribution problem: identify which build step introduced it, whether the tag was republished, and whether the same credential exists elsewhere. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because it explains why long-lived embedded secrets create much larger blast radius than ephemeral alternatives.
In environments with nested build stages, caching proxies, or ad hoc image promotion, this approach tends to break down because the scanner is pointed at a registry tag instead of the resolved digest and its per-platform layer set.
Common Variations and Edge Cases
Tighter coverage often increases scan volume and registry churn, so teams need to balance completeness against build latency and false-positive handling. Not every repository requires the same depth, but multi-architecture images and frequently retagged images deserve the strictest treatment because their content changes underneath a stable name.
One common edge case is the difference between tag drift and digest stability. If a pipeline promotes by tag alone, yesterday’s approval may no longer describe today’s image. Another is architecture skew: a secret may exist only in an arm64 build because a conditional step or vendor package is different from amd64. Current guidance suggests treating platform variants as distinct security artefacts whenever the build matrix is not perfectly symmetrical.
Another practical issue is remediation ownership. A scanner can tell you that a secret exists, but it cannot decide whether the correct fix is rebuild, rotate, revoke, or quarantine. That decision depends on whether the secret is still valid, whether the image has reached production, and whether the leaked value appears anywhere else. The right response is usually faster when scan results are linked to asset ownership and credential lifecycle data rather than security tickets alone.
Risk and Threat Considerations
The main risk is exposure of valid credentials in artefacts that are widely distributed, cached, and hard to fully retract once published. Multi-architecture repositories increase that exposure because one clean variant can create false confidence while another variant still contains a usable secret.
Failure mechanism: The weakness usually appears when teams scan only a tag, only a default architecture, or only the latest manifest entry. Attackers and internal users alike can pull the unscanned variant, extract the embedded secret from image layers or metadata, and use it for downstream access before rotation or revocation closes the window.
Impact: The result can be credential reuse, registry compromise, lateral access into dependent services, or long-lived exposure if the secret remains valid after the image is fixed. In container environments, the damage is often amplified by replication, because the same image may be pulled into multiple clusters, caches, and developer environments.
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 | 6 — Access Control Management | Secrets in images create unauthorized access paths that must be limited and revoked. |
| 8 — Audit Log Management | Scanning every tag and architecture depends on traceable image and build events. | |
| 16 — Application Software Security | Container builds are application artefacts that should be checked for embedded secrets. | |
| Recommendation — Revoke exposed credentials and restrict who can publish or pull sensitive image artefacts. Log image digests, pulls, and build outputs so leaks can be traced to a specific variant. Scan build outputs before release and block images that contain embedded credentials. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Embedded secrets expand access scope when images are pulled or reused broadly. |
| DE.CM — Security Continuous Monitoring | Every tag and architecture needs continuous inspection to avoid blind spots. | |
| RC.RP — Response Planning | Secret findings require coordinated rebuild, rotation, and validation actions. | |
| Recommendation — Enforce least privilege for image access and rotate credentials found in published layers. Continuously monitor all published manifests and digests for secret exposure. Prepare a response playbook that rebuilds images and revokes leaked secrets quickly. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Hardcoded secrets in image layers are a direct unsecured-credential exposure pattern. |
| T1204 — User Execution | Users or pipelines may unknowingly run images that carry embedded secret material. | |
| Recommendation — Hunt for embedded credentials in image layers and treat any discovery as credential compromise. Validate image provenance before deployment so untrusted artefacts are not executed. | ||
Practitioner Guidance
What to verify: Confirm that your scanner resolves every tag to immutable digests and expands each manifest list into all platform variants before judging the repository clean. If the tool only reports on a single image reference, it is not giving you complete assurance for multi-architecture publishing.
Decision rule: If a leaked value is still valid, prioritise credential rotation and downstream access review before chasing the exact build step that introduced it. If the secret is already revoked, focus on rebuild verification, tag republishing, and evidence that no other published variant still contains the same material.
Practitioner takeaway: The real control objective is variant-level coverage with actionable results, because a container image is only as safe as its least-scrutinised tag or architecture.
Related resources from NHI Mgmt Group
- How should security teams implement secrets management across the SDLC without creating onboarding friction or hidden misconfigurations?
- How should security teams scan Elasticsearch for secrets without creating duplicate work or noise?
- How should security teams scan for secrets in deleted or private GitHub commits without missing hidden attack surface?
- How should security teams manage secrets in Docker images?
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
