AWS ECR Security: Container Image Scanning and Registry Protection

Container registries are often overlooked in security assessments — they're infrastructure, not application code, so they don't get the same scrutiny as the workloads they serve. But a compromised container registry is a significant supply chain risk: an attacker who can push images to your registry can inject malicious code into your production deployments. And a registry that doesn't scan for vulnerabilities is distributing known-vulnerable software with each deployment.

ECR's security capabilities have expanded significantly, making it practical to build a secure-by-default registry workflow that catches vulnerabilities before deployment and prevents unauthorized image modification.

Image Scanning with Amazon Inspector

Enable Amazon Inspector continuous scanning for all ECR repositories. Inspector scans images when they're pushed and continuously re-evaluates existing images as new CVE data becomes available. An image that was clean when pushed may develop findings as new vulnerabilities are discovered and matched against its installed packages.

Configure scan on push at the registry level (applies to all repositories) or at the individual repository level. For production repositories, continuous scanning with Inspector is preferred over basic scanning (which only scans on push and uses an older scanning engine). Inspector provides OS package and programming language package scanning, covering a broader surface area than basic scanning.

Integrate Inspector findings into your CI/CD pipeline to block deployment of images with HIGH or CRITICAL vulnerabilities:

aws ecr describe-image-scan-findings   --repository-name my-app   --image-id imageTag=latest   --query 'imageScanFindings.findingSeverityCounts'

If CRITICAL or HIGH counts are non-zero, fail the deployment. This creates a forcing function for addressing vulnerabilities in dependencies rather than shipping known-vulnerable images to production.

Repository Access Control

ECR repositories support resource-based policies (repository policies) and IAM identity-based policies. Configure repository policies to restrict which accounts and principals can push images:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/CIDeploymentRole"
      },
      "Action": ["ecr:PutImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload"],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "ecr:PutImage",
      "Condition": {
        "ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/CIDeploymentRole"}
      }
    }
  ]
}

This policy allows only the CI/CD deployment role to push images. All other principals are denied push access, even if their IAM policies would otherwise permit it. Restricting image push to CI/CD systems ensures that all production images go through your security scanning pipeline before deployment.

Image Tag Immutability

Without tag immutability, any authorized principal can overwrite an existing image tag with a different image. This means the image running as my-app:latest today might be a different image tomorrow if someone pushes a new image with the latest tag. This is both a security risk (malicious image replacement) and an operational risk (unexpected application behavior from silently replaced images).

Enable tag immutability on production repositories to prevent tag overwriting:

aws ecr put-image-tag-mutability   --repository-name my-app   --image-tag-mutability IMMUTABLE

With immutable tags, deploying a new version requires a new tag (a version bump, a commit hash, or a build number). This is better practice anyway — using specific version tags rather than latest makes deployments reproducible and rollback straightforward.

Cross-Account Image Access

For organizations where a central registry serves multiple accounts (a common pattern in multi-account architectures), configure cross-account repository policies to allow specific accounts to pull images without requiring the images to be replicated to each account.

The central registry account grants pull permission to production account roles. The pull operation authenticates using a temporary token from the central account's ECR authorization service. This centralization means vulnerability scanning only needs to run in one place, and image provenance is maintained across all accounts using a given image.

Lifecycle Policies for Storage Management

Without lifecycle policies, ECR repositories grow indefinitely as new images are pushed. Implement lifecycle policies to remove old images and reduce storage costs:

{
  "rules": [{
    "rulePriority": 1,
    "selection": {
      "tagStatus": "untagged",
      "countType": "imageCountMoreThan",
      "countNumber": 10
    },
    "action": {"type": "expire"}
  }, {
    "rulePriority": 2,
    "selection": {
      "tagStatus": "tagged",
      "tagPrefixList": ["feature-"],
      "countType": "sinceImagePushed",
      "countUnit": "days",
      "countNumber": 30
    },
    "action": {"type": "expire"}
  }]
}

This policy keeps the 10 most recent untagged images (useful for rolling deployments) and removes feature-branch images after 30 days.

Related Reading

• ECS security — using ECR images securely in ECS deployments
• EKS security — ECR integration for Kubernetes workloads
• GuardDuty setup — GuardDuty ECR protection for runtime threat detection
• IAM security best practices — access control design for ECR repositories

FAQ

Does Amazon Inspector scan every layer in a container image?

Inspector scans the packages installed in the container image across all layers. It checks against the NVD (National Vulnerability Database) and AWS Security Advisories for OS packages (RPM, DEB) and programming language packages (pip, npm, gem, maven, etc.). It doesn't perform dynamic analysis of the container's runtime behavior — it's static analysis of installed packages and versions.

Can I use non-ECR registries with ECS and EKS?

Yes. ECS and EKS can pull images from any accessible container registry — Docker Hub, GitHub Container Registry, or private registries — with appropriate credentials. Using ECR has practical advantages: native IAM authentication (no long-lived registry credentials), tight Inspector scanning integration, and no egress charges for pulls within the same region and account. For external registries, configure appropriate image pull secrets and ensure scanning is handled at the source or before images reach your deployment pipeline.

How does ECR handle image signatures for supply chain security?

ECR supports container image signing through Notation (the CNCF supply chain security standard). Images can be signed using an AWS Signer key, and ECR provides a reference for verifying signatures. Policy enforcement at the Kubernetes layer (using OPA Gatekeeper or Kyverno) can require images to have valid signatures before they're admitted to a cluster. This prevents deployment of unsigned or improperly signed images even if an attacker were able to push a malicious image to the registry.