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 = falsewhen noimage_scanning_configurationblock is present, so omitting the block creates a non-compliant repository. Modules that accept an optional scanning variable and default it tonullhave 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_pushflag) and enhanced scanning (Amazon Inspector, configured account-wide viaaws_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 theirscan_on_pushflag isfalse.Existing images are not retroactively scanned
Call
aws ecr start-image-scanfor any image tags already present when you enablescan_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_enabledAWS Config Managed Rules:
ECR_PRIVATE_IMAGE_SCANNING_ENABLED,INSPECTOR_ECR_SCAN_ENABLEDCheckov Check:
CKV_AWS_163Powerpipe Control:
aws_compliance.control.ecr_repository_image_scan_on_push_enabledProwler Checks:
ecr_registry_scan_images_on_push_enabled,ecr_repositories_scan_images_on_push_enabledAWS Security Hub Control:
ECR.1Trivy Check:
AWS-0030
Last reviewed: 2026-03-09