Skip to content

ECR repositories should have image scan on push enabled

Container images pulled from public registries or built in CI pipelines regularly contain known CVEs in OS packages and application dependencies. Scan-on-push runs every image through Amazon Inspector or ECR basic scanning before it can reach a cluster, catching issues at the earliest point in the pipeline.

Without automated scanning, vulnerable images accumulate silently. Teams find out after an incident or a periodic manual audit, by which point the blast radius has grown.

Retrofit consideration

Enabling scan-on-push on existing repositories only applies to images pushed after the change. Images already in the repository won't generate findings until they're re-pushed or explicitly scanned via aws ecr start-image-scan.

Implementation

Choose the approach that matches how you manage Terraform.

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

module "ecr" {
  source  = "pcidss.compliance.tf/terraform-aws-modules/ecr/aws"
  version = ">=2.0.0"

  create_lifecycle_policy = false
  repository_name         = "abc123"
}

module "ecr" {
  source  = "nistcsf.compliance.tf/terraform-aws-modules/ecr/aws"
  version = ">=2.0.0"

  create_lifecycle_policy = false
  repository_name         = "abc123"
}

module "ecr" {
  source  = "acscessentialeight.compliance.tf/terraform-aws-modules/ecr/aws"
  version = ">=2.0.0"

  create_lifecycle_policy = false
  repository_name         = "abc123"
}

module "ecr" {
  source  = "nistcsfv11.compliance.tf/terraform-aws-modules/ecr/aws"
  version = ">=2.0.0"

  create_lifecycle_policy = false
  repository_name         = "abc123"
}

If you use terraform-aws-modules/ecr/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "ecr" {
  source  = "terraform-aws-modules/ecr/aws"
  version = ">=2.0.0"

  create_lifecycle_policy = false
  repository_name         = "abc123"
}

Use AWS provider resources directly. See docs for the resources involved: aws_ecr_repository.

resource "aws_ecr_repository" "this" {
  name = "pofix-abc123"

  image_scanning_configuration {
    scan_on_push = true
  }
}

What this control checks

The aws_ecr_repository resource must include an image_scanning_configuration block with scan_on_push = true. Omitting the block is equivalent to setting it false: AWS applies that default, and the repository fails. To pass, declare:

resource "aws_ecr_repository" with image_scanning_configuration { scan_on_push = true }.

Any explicit false value or missing block results in a non-compliant evaluation. No other arguments in the resource affect this control.

Common pitfalls

  • Default is false when block is omitted

    Terraform applies the AWS default of scan_on_push = false when no image_scanning_configuration block is present, so omitting the block creates a non-compliant repository. Modules that accept an optional scanning variable and default it to null have the same problem, and the failure won't surface until policy evaluation runs.

  • Basic scanning vs Enhanced scanning confusion

    ECR has two scanning modes: basic scanning (per-repository, controlled by the scan_on_push flag) and enhanced scanning (Amazon Inspector, configured account-wide via aws_ecr_registry_scanning_configuration). This control checks the per-repository flag. If you've enabled enhanced scanning at the account level with continuous or on-push filters, individual repositories can still fail this check if their scan_on_push flag is false.

  • Existing images are not retroactively scanned

    Call aws ecr start-image-scan for any image tags already present when you enable scan_on_push, or re-push those images. The flag only kicks in for images pushed after it's set.

  • Cross-region replication does not copy scan settings

    AWS auto-creates destination repositories when replication runs, and those repositories don't inherit scan_on_push = true. Pre-create the destination repositories in Terraform with the flag set before replication runs, otherwise every replicated repo fails this control.

Audit evidence

The primary audit artifact is the Config rule evaluation for ecr-repository-image-scan-on-push-enabled showing all in-scope repositories as COMPLIANT. Supporting evidence includes the ECR console showing "Scan on push" as Enabled per repository, or output from aws ecr describe-repositories with imageScanningConfiguration.scanOnPush as true for every repository in scope. Scan finding summaries from Inspector or ECR basic scanning confirm the control is operational, not just configured. CloudTrail entries for PutImageScanningConfiguration establish when the setting was enabled and by whom.

Framework-specific interpretation

PCI DSS v4.0: Requirement 6.3.1 wants all security vulnerabilities in custom and third-party software components identified and managed. Automated ECR scanning catches known CVEs in base images and package layers before they reach a cardholder data environment.

NIST Cybersecurity Framework v2.0: Scan-on-push covers both the Protect and Detect functions. PR.PS outcomes call for protective controls on software and assets; DE.CM calls for detecting vulnerabilities before they're exploited. One configuration flag addresses both.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: ecr_repository_image_scan_on_push_enabled

  • AWS Config Managed Rules: ECR_PRIVATE_IMAGE_SCANNING_ENABLED, INSPECTOR_ECR_SCAN_ENABLED

  • Checkov Check: CKV_AWS_163

  • Powerpipe Control: aws_compliance.control.ecr_repository_image_scan_on_push_enabled

  • Prowler Checks: ecr_registry_scan_images_on_push_enabled, ecr_repositories_scan_images_on_push_enabled

  • AWS Security Hub Control: ECR.1

  • Trivy Check: AWS-0030

Last reviewed: 2026-03-09