Uncover Secrets in CodeCommit and Docker

What this lab covers

You inspect container images for material their authors believed they had removed, and enumerate a source repository for the same class of mistake in commit history.

The two halves share one property. Both Docker images and git repositories are append-only in practice, so removal in a later step does not remove anything, and both are routinely distributed to more people than the author expected.

It assumes no prior AWS or Docker experience and is a good complement to the git secret scanning lab.

How container layers and repositories retain secrets

Each instruction in a container build produces a layer, and the resulting image is the accumulation of all of them. A file added in one layer and deleted in a later one is not present in the final filesystem view, and it remains in the layer where it was added.

That layer is available to anyone who can pull the image, and inspecting layers requires only standard tooling. Build arguments and environment variables are similarly preserved in image metadata, which catches teams who pass secrets at build time believing they are transient.

Source repositories have the same property for the same reason. Commit history retains everything, so a credential committed and removed later remains readable, and a private repository is only as private as the access list, which typically grows over time.

How to detect this in your own environment

Scan images in your registry, not just your Dockerfiles. The Dockerfile shows intent and the image shows what was actually built, and layer-aware scanning is what finds the difference.

Scan repository history rather than working trees, across all branches. A working tree scan is the most common reason organizations believe their repositories are clean.

Detect on the cloud side too, since it is faster. First use of a credential from an unfamiliar network usually surfaces before any scanning finds the artifact it came from.

How to prevent it

Use multi-stage builds and build secret mounts so credentials are available during the build without being written to a layer. This is the mechanism designed for the problem and it works.

Never pass secrets as build arguments, since they are retained in image metadata and readable by anyone who inspects the image.

Rotate anything that has ever been in a layer or a commit. Rebuilding the image and rewriting history are worth doing and neither addresses copies already pulled or cloned.

Real-world context

Research scanning public container registries has repeatedly found credentials in image layers, including keys for cloud providers and third-party services. The rate has stayed high because the mistake is easy to make and invisible in the final image.

The same applies to private registries with broad internal access. An image pulled by every developer and every build agent is not meaningfully restricted, and its layers are readable by all of them.

The pattern maps to MITRE ATT&CK T1552.001 Credentials In Files and T1078.004 Cloud Accounts.

Applying this at work

• Run layer-aware secret scanning across the images in your registries, including older tags.
• Check whether any of your builds pass secrets as build arguments, and move them to build secret mounts.
• Adopt multi-stage builds so build-time credentials never reach the final image.
• Scan full repository history across all branches, not just the current files.
• Rotate any credential found, and treat rebuilding and history rewriting as cleanup that follows rotation.

Frequently asked questions

Does deleting a file in a Dockerfile remove it from the image?

No. Each instruction creates a layer, and deletion adds a layer marking the file as removed while the earlier layer still contains it. Anyone who pulls the image can read it.

Are build arguments a safe way to pass secrets?

No. Build arguments are retained in image metadata and readable by anyone inspecting the image. Build secret mounts exist specifically to provide credentials during a build without persisting them.

What is the correct remediation for a secret found in a layer?

Rotate it first. Rebuilding the image without the secret is necessary and does not help with copies already pulled, so the credential must be considered compromised regardless.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.