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

Basic ECR image scanning only starts a scan when a matching push event occurs. 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.
• Query scan findings for a specific, currently-deployed historical tag.

aws ecr describe-registry-scanning-configuration
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 pushed before the setting was enabled typically show a null or missing scan status, and the findings query for those tags returns a ScanNotFoundException rather than a findings summary.

Correction

Close the gap by moving the affected repository from push-only basic scanning to continuous, registry-level enhanced scanning so existing and future images are both covered, without waiting for a new push. Scope the change narrowly to the repository under review rather than applying it registry-wide in one step, and capture the existing configuration first so the change stays reversible.

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

This is a configuration change, not a destructive action: it does not delete, overwrite or remove 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.