ECR Scan-on-Push Leaves Old Container Images Permanently Unscanned

Amazon ECR’s basic image scanning is often treated as a set-and-forget control: turn on scan on push, and the registry is assumed to be covered. That assumption breaks down for every image that already existed in the repository before the setting was applied, and for every image pushed while scanning was temporarily disabled. This walkthrough covers a bounded, non-production validation of that gap using Amazon Web Services APIs, with explicit rollback if a later scanning change needs to be reverted.

Symptom

A private ECR repository with scan on push enabled shows a clean vulnerability dashboard for recent pushes, yet several tags that are still referenced by running tasks or deployments report no scan findings at all. Security reporting built from ECR’s scan status looks uniformly green even though a meaningful share of the images it is supposed to cover have never actually been examined.

False Assumption

The working assumption on the platform team is that enabling scan on push retroactively scans every image already sitting in the repository, so turning the setting on is treated as equivalent to a one-time, full-repository vulnerability sweep. In practice, scan on push is a trigger tied to the push event itself, not a standing audit of everything already stored in the repository.

Root Cause

With basic ECR image scanning, scan on push triggers a scan when an image is pushed. A basic scan can also be started manually with start-image-scan, limited to once per image every 24 hours. Images that were already stored in the repository before scan on push was enabled, and images pushed during any period when the setting was off, never generate that trigger, so their scan status stays empty or stale indefinitely unless someone manually re-scans them or the registry is moved to continuous scanning. The setting describes future behaviour at the point it is turned on; it says nothing about the current contents of the repository.

Impact

Vulnerability management coverage silently excludes every historical image still in active use, so a container running a known, patchable CVE can continue to pass scan-based deployment gates simply because no scan record exists to fail against. The exposure is highest for long-lived base images, digests still pinned by older task definitions, and any repository that was already in use before scanning was enabled.

Diagnosis

Confirm the gap with read-only checks before changing anything, comparing the registry’s declared scanning configuration against the actual scan status recorded on individual images.

• Read the registry’s current scanning mode and scope.
• List images in the affected repository with push date and scan status.
• Check the repository-level scan on push setting.
• Query scan findings for a specific, currently-deployed historical tag.

aws ecr describe-registry-scanning-configuration
aws ecr describe-repositories --repository-names  --query 'repositories[].imageScanningConfiguration.scanOnPush'
aws ecr describe-images --repository-name <repository> --query 'imageDetails[].{tag:imageTags[0],pushed:imagePushedAt,status:imageScanStatus.status}'
aws ecr describe-image-scan-findings --repository-name <repository> --image-id imageTag=<tag>

Images that have never been scanned typically show a null or missing scan status, and the findings query for those tags returns a ScanNotFoundException rather than a findings summary. Images that were scanned manually show findings.

Correction

Close the gap by moving from push-only basic scanning to continuous enhanced scanning so existing and future images are both covered, without waiting for a new push. Enhanced scanning requires Amazon Inspector and incurs additional cost. The scanning configuration is a single setting per registry per region, and put-registry-scanning-configuration overwrites the whole configuration, so the change is registry-wide for that region. Save the output of describe-registry-scanning-configuration first, and merge any existing rules with the new rule instead of replacing them.

aws ecr put-registry-scanning-configuration --scan-type ENHANCED --rules '[{"scanFrequency":"CONTINUOUS_SCAN","repositoryFilters":[{"filter":"<repository>","filterType":"WILDCARD"}]}]'

This call replaces the registry scanning configuration, so include every existing rule you want to keep alongside the new one. It does not delete or alter any image, tag or repository.

Validation

Confirm the fix by re-checking the same images that previously showed no scan record. After enabling enhanced scanning, re-run the describe-images and describe-image-scan-findings checks against a sample of previously unscanned tags and confirm each now returns a completed scan with a findings summary rather than a missing status or a ScanNotFoundException.

• Re-run the registry configuration check and confirm scanType reports ENHANCED with the intended repository filter only.
• Re-run the image listing check and confirm scan status has moved from null to COMPLETE for images still in active use.
• Re-query findings for at least one previously unscanned tag and confirm a scan completion timestamp is now present.

Treat any tag that still shows no scan record after the documented enhanced-scanning backlog window as a separate diagnostic finding, not as proof the change failed outright.

Rollback

Revert to the prior scanning configuration if continuous scanning produces an unacceptable volume of findings or cost before the backlog has been triaged.

1. Before changing anything, save the output of describe-registry-scanning-configuration as the rollback baseline.
2. To revert, reapply put-registry-scanning-configuration using the saved baseline scanType and rules exactly as recorded.
3. Confirm rollback by re-running describe-registry-scanning-configuration and checking the output matches the saved baseline.

Neither the original change nor the rollback deletes or alters any stored image, so there is no image-level recovery step required.

Prevention

Treat scan on push as a forward-looking trigger, not a retroactive guarantee, in every ECR repository review. Make continuous or enhanced scanning the default for any repository that predates the scanning rollout, and add an explicit check for images with a missing or stale scan status to routine repository audits rather than relying on the toggle alone.

• Record the date scanning was enabled for each repository so historical coverage gaps are traceable.
• Alert on images whose scan status stays null beyond the expected scan window.
• Where enhanced scanning cannot be justified for cost or scope reasons, schedule a recurring manual rescan of long-lived, still-deployed images instead of assuming the initial toggle covered the whole inventory.

Related reading

• Switching a Key Vault to RBAC Keeps Old Access Policies, Inactive but Not Deleted
• AWS Identity Controls Leave Workloads Exposed Until Verified
• AWS Site-to-Site VPN Tunnel Down After BGP Flap to Azure: Fix
• Fixing AWS S3 AccessDenied When an EC2 Instance Role Reads a Bucket