Why does scanning only the default Docker architecture miss some leaked secrets?

Scanning only the default architecture can miss secrets because platform-specific variants are stored as separate manifest digests and may contain different filesystem layers. A secret added to one build but not another will not appear in the default image scan. Teams need to treat each architecture as a distinct exposure surface, not as a duplicate copy of the same artifact.

Why Default-Architecture Scans Miss Leaked Secrets

Docker architecture is not just a label on the same image. A multi-platform image can resolve to different manifest digests, and each digest can point to different filesystem layers. That means a secret introduced in one build variant may never exist in the default variant your scanner inspects. In practice, a “clean” result on one architecture can hide a real exposure on another.

This matters because teams often assume a registry scan covers the whole image family, when in fact it only covers the platform they asked for or the platform the tool chose by default. The result is a false sense of completeness: the vulnerable path is still present, but only in the variant that was not examined. Current secrets data also shows why that blind spot is expensive; NHIMG’s The 2024 State of Secrets Management Survey found that the average time to mitigate a leaked secret is 36 hours, so missed detection can prolong exposure well beyond the first build cycle.

In practice, many teams discover the omitted architecture only after a deployment, when the “same” image behaves differently across nodes or cloud targets.

How It Works in Practice

A multi-architecture Docker image is usually published as a manifest list, which acts like an index for several platform-specific images. Each image variant can have its own layers, its own build history, and its own content. If a secret is baked into an amd64 layer but not into arm64, scanning only the default variant will miss the amd64 exposure entirely. The inverse is also true. The problem is not that scanners are useless; it is that the scan scope is narrower than the artifact family you actually ship.

The practical response is to treat each architecture as a distinct exposure surface. That means inventorying which platforms you publish, verifying that your scanner resolves every manifest digest, and checking whether the tool scans the manifest list only or also walks each child image. If your build process produces per-architecture variants from separate stages, you also need to validate that secrets are never copied into one platform-specific branch and then “fixed” in another. For containerised supply chains, this is especially important when build automation signs, promotes, or replicates images without re-scanning every digest. NHIMG’s Guide to the Secret Sprawl Challenge is useful context because it frames secret exposure as a distribution problem, not just a code problem.

Scan the manifest list and every platform-specific digest, not just the default pull target.
Record which architectures are built, promoted, and deployed in each environment.
Compare findings across architectures to spot secrets present in only one variant.
Trigger re-scans after image promotion, because a new digest can introduce a new layer set.

For a deeper architectural reference, the OWASP Non-Human Identity Top 10 is helpful when the missed secret is a machine credential rather than ordinary text, because the control problem is then both image-scanning and credential governance. These controls tend to break down when teams rely on a single default platform in mixed-architecture clusters, because the registry view no longer matches the runtime reality.

Common Variations and Edge Cases

Broader scanning usually increases build and analysis overhead, so teams have to balance completeness against release speed. That tradeoff becomes sharper in organisations that publish many variants, use cross-compilation, or rebuild images frequently for different runtimes.

One common edge case is when the secret is not in application source at all but in a platform-specific layer created by a late build step, such as a package install, injected config file, or debugging artifact. Another is when one architecture is rebuilt from a different base image, which can change layer ancestry enough to shift what is exposed. Best practice is evolving here: there is no universal standard for whether a registry control or CI control should own multi-arch verification, so ownership needs to be explicit. For operational teams, the safest assumption is that each digest can fail independently, even if the tags appear identical.

When the question is about leaked secrets rather than general image hygiene, the important signal is not “did the tag scan pass?” but “was every shipped digest examined before promotion?” NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful complement when the leaked value is long-lived, because static credentials increase the cost of any architecture-level miss.

If the pipeline publishes a manifest list from multiple independently built images, default-only scanning is too coarse to trust.

Risk and Threat Considerations

The material risk is hidden secret exposure across otherwise similar image variants. That creates a control gap in which one architecture appears clean while another still contains a usable credential, token, or key. Attackers and internal misusers do not need the “default” image; they only need the variant that still carries the secret.

Failure mechanism: A scanner resolves only one manifest digest, so the organisation validates a subset of the released image family. Because each architecture can carry separate layers, the leaked secret survives in a non-default variant and escapes detection, rotation, and revocation.

Impact: The exposed secret can be used for lateral access, API abuse, registry access, or cloud compromise, and the missed finding can persist until a separate deployment path or incident reveals it.

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	CIS 16 — Application Software Security	Per-arch scanning is part of secure software release validation.
	CIS 3 — Data Protection	Leaked secrets are sensitive data that need discovery and containment.
	CIS 12 — Network Infrastructure Management	Multi-arch registry and deployment paths expand infrastructure exposure points.
Recommendation — Scan every shipped image digest before promotion and block releases with embedded secrets. Inventory and protect secrets so leaked credentials are detected and rotated quickly. Map image distribution paths and verify each registry artifact is covered by inspection.
MITRE ATT&CK	T1552 — Unsecured Credentials	The issue is exposure of credentials embedded in image layers.
Recommendation — Hunt for embedded credentials in image layers and rotate any exposed secret immediately.
NIST CSF 2.0	PR.DS — Data Security	Secrets in image layers are data assets needing protection across variants.
Recommendation — Apply data protection checks to every image variant that can reach production.

Practitioner Guidance

What to verify: Confirm whether your scan workflow inspects the manifest list and every child digest, not only the tag or default platform. If it does not, treat the result as incomplete rather than clean.

Decision rule: If a platform-specific digest can ship independently, require per-digest secret scanning before promotion and rotation after any positive finding. A single cleared architecture should never be accepted as evidence that the image family is safe.

What practitioners underestimate: Teams often focus on the build that they test locally, while production may pull a different architecture entirely. That mismatch is where missed secrets survive.

Practitioner takeaway: The control objective is variant-level visibility, not tag-level reassurance; if you cannot prove each shipped digest was scanned, you cannot claim the secret was not present.