Description

Ensure that the most recently pushed image in each Amazon Elastic Container Registry (ECR) repository contains no hardcoded secrets, such as passwords, access keys, API tokens or private keys. Environment variables, build history (Dockerfile ENV, ARG and RUN instructions) and every filesystem layer are scanned. For multi-architecture images only one platform image is scanned, and images that cannot be fully retrieved are reported for manual review.

Rationale

Anyone who can pull an image can read every secret embedded in it, and images are often copied to other registries, build caches and developer machines. Leaked credentials can give attackers access to databases, APIs and cloud resources, and are hard to revoke once the image has been distributed. Secrets should never be built into images: use build-time secret mounts instead of ENV or ARG, provide secrets at runtime from AWS Secrets Manager or AWS Systems Manager Parameter Store, and scan images for secrets before pushing them.

Impact

  • Prevents credential exposure to anyone with pull access to the repository

  • Requires changes to the Dockerfile and build process, and the application must read secrets at runtime

  • Exposed credentials must be rotated, which may require coordination with the owners of the affected systems

  • Deleting compromised images can break deployments that still reference them

Default Value

Amazon ECR does not scan images for secrets and does not prevent images containing secrets from being pushed.

Pre-Requisites

  • IAM permissions: ecr:DescribeRepositories, ecr:DescribeImages, ecr:GetAuthorizationToken, ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, ecr:BatchDeleteImage and the permissions needed to push images

  • Access to the image source code, Dockerfile and build pipeline

  • A plan to rotate each exposed credential with the owner of the affected system

Remediation

Test Plan

Console:

  1. Sign in to the AWS Management Console at https://console.aws.amazon.com.

  2. Open the Amazon ECR console and select Repositories under Private registry.

  3. Open each repository and identify the most recently pushed image.

  4. Pull that image and review its environment variables, build history and files, for example with docker image inspect and docker history --no-trunc, or with a secret scanning tool.

  5. Repeat for each repository in each region in use.

  6. If any secret is found, follow the implementation steps.

CLI:

Show the digest and tags of the most recently pushed image in a repository:

aws ecr describe-images --repository-name <REPOSITORY_NAME> --region <REGION> --query "sort_by(imageDetails,&imagePushedAt)[-1].[imageDigest,imageTags,imagePushedAt]" --output table

An image fails if a potential secret is found in its environment variables, in any build history step, or in a file in any of its layers. Only the most recently pushed image of each repository is evaluated; for a multi-architecture image, one platform image is scanned. If the image manifest cannot be retrieved, or part of the image cannot be retrieved or exceeds the size limits, the image is reported for manual review instead of passing.

Implementation Steps

Console:

  1. Remove the secret from the Dockerfile (ENV, ARG or RUN instructions) and from any file copied into the image.

  2. Change the application to read the secret at runtime, for example from AWS Secrets Manager or Parameter Store through the ECS task definition, the EKS Secrets Store CSI driver or the application code. If the secret is needed during the build, use a build secret mount (--mount=type=secret).

  3. Rebuild the image and push it to the repository.

  4. Rotate the exposed credential immediately.

  5. In the Amazon ECR console, open the repository, select the image versions that contain the secret and choose Delete.

  6. Repeat for each affected repository in each region in use.

CLI:

Delete an image that contains a secret:

aws ecr batch-delete-image --repository-name <REPOSITORY_NAME> --image-ids imageDigest=<IMAGE_DIGEST> --region <REGION>

Backout Plan

Before deleting an image, pull it and keep a local copy, and confirm that no running service still references it.

  1. Push the saved image back to the repository with its original tag.

  2. Restore the previous Dockerfile and application configuration from version control.

  3. Redeploy the services that used the previous image.

Note: rolling back re-exposes the embedded secret to anyone with pull access. Credentials that were rotated cannot be restored and remain invalid.

Reference