Image layers are the stacked filesystem and metadata changes that form a container image during build. Anything written into a layer can persist even if later deleted in the Dockerfile. That makes layers a common place where secrets survive, especially when build steps expose credentials before final packaging.
Expanded Definition
Image layers are the immutable or semi-immutable filesystem and metadata deltas that container build systems stack to produce a runnable image. Each instruction in a Dockerfile or similar build spec can create a new layer, and that layer may preserve files, command outputs, environment variables, and package state even when later steps try to remove them. For NHI Management Group, the security significance is straightforward: layers can preserve secrets, build artefacts, and sensitive configuration in places that are not visible in the final runtime filesystem but still exist in the image history.
This concept is often confused with the final container filesystem. That confusion matters because a deleted file in a later layer may still be recoverable from an earlier one, and image inspection tools can expose the provenance of the build. In practice, image layers sit at the intersection of supply chain security, secret hygiene, and image provenance. The NIST Cybersecurity Framework 2.0 is useful here because it frames asset protection and secure configuration as governance concerns, not just build-time chores. The most common misapplication is treating a clean final image as proof that no sensitive material was ever written into an earlier layer, which occurs when teams rely on delete commands instead of preventing secret exposure during the build.
Examples and Use Cases
Implementing image-layer hygiene rigorously often introduces build complexity, requiring organisations to weigh reproducibility and convenience against a stricter separation of secrets from build artefacts.
- A developer copies a private package token into the image so dependencies can install, then deletes the file later. The token can still persist in an earlier layer and be extracted from the image history.
- A CI pipeline writes cloud credentials into a temporary file during build. Even if the file is removed before release, the layer may still retain the content and expose it to anyone with registry access.
- A security team reviews a production image with Docker image history or similar tooling to identify unexpected commands, packages, or embedded metadata that should not be present.
- An organisation uses multi-stage builds to keep compilers, test fixtures, and build-time secrets in an intermediate stage rather than shipping them in the final runtime image.
- A platform team scans image layers during release approval to confirm that no API keys, certificates, or privileged configuration were written into build contexts or copied from developer workstations.
These use cases align with the broader supply chain guidance in NIST guidance on application container security, which treats image construction as a trust boundary that must be controlled and reviewed.
Why It Matters for Security Teams
Image layers matter because they can turn a routine build mistake into a durable exposure. Once a secret is written into a layer, revoking the credential may reduce live risk, but it does not erase the historical artefact already distributed through registries, caches, and developer machines. That creates a long-tail problem for incident response, compliance, and access governance. Security teams need to understand image layers when evaluating source-to-image pipelines, because the control failure is often upstream of runtime defence tools such as EDR or SIEM. In containerised environments, layers are also relevant to NHI governance when service credentials, workload certificates, or signing material are introduced during build and then propagated into images.
Practitioners should pair least-privilege build design with secret-injection patterns that keep credentials out of the filesystem entirely, and they should validate that registry retention and cache policies do not preserve sensitive layers longer than intended. The image itself may appear hardened while the underlying build trail remains exposed. Organisations typically encounter the impact only after a leak, a registry compromise, or an image forensics review, at which point image layers become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Protect data at rest, including secrets that may persist inside image layers. |
| NIST SP 800-53 Rev 5 | CM-6 | Configuration settings and build outputs should be controlled to avoid embedded sensitive content. |
| ISO/IEC 27001:2022 | A.8.9 | Configuration management covers secure handling of system and software build artefacts. |
| NIST SP 800-63 | Digital identity guidance is relevant when credentials or authenticators are embedded during builds. | |
| OWASP Non-Human Identity Top 10 | NHI guidance addresses workload secrets and service identities that commonly leak into layers. |
Standardise container build configurations and prohibit secret material in image layers.
Related resources from NHI Mgmt Group
- What does the hardcoded credential in a Docker image breach scenario teach us?
- Why do image scanners miss some container supply chain attacks?
- What is the difference between static image security and runtime container security?
- How should security teams govern AI agents that use multiple identity layers?
