Container images move fast — pulled, rebuilt, and redeployed dozens of times a day — which means a vulnerable base layer can slip into production long before anyone notices. If your team pushes images to Amazon Elastic Container Registry (ECR), AWS ECR image scanning is the fastest way to close that gap: it inspects image layers for known CVEs the moment they're pushed, without requiring a separate scanning service bolted onto your pipeline. This guide walks through enabling basic and enhanced scanning, turning on scan-on-push so nothing reaches your registry unchecked, wiring scans into CI/CD, and pulling findings programmatically so they actually get triaged instead of sitting in a console tab. By the end, you'll have a repeatable ECR vulnerability scanning setup that catches known-bad packages before they ship, plus a troubleshooting checklist for the errors teams hit most often when scans silently fail or return incomplete results.
Why AWS ECR Image Scanning Matters for Your Supply Chain
Most container CVEs don't originate in your application code — they arrive through base images and OS packages you never directly touch. A stale node:18 or python:3.11-slim tag can carry dozens of known vulnerabilities inherited from upstream. Native ECR scanning gives you visibility without standing up a separate tool, and because it's built into the registry, it's the one check that runs regardless of which CI system pushed the image. That said, native scanning is a detection layer, not a policy engine — it tells you what's wrong but not always what to fix first or how it maps to exploitability, which is where the later sections on triage come in.
Step 1: Choose Between Basic and Enhanced Scanning
AWS offers two scanning tiers, and picking the right one up front saves rework later:
- Basic scanning uses the Clair open-source engine, checks OS package vulnerabilities against the CVE database, and runs on push or on a manual/scheduled basis. It's free and sufficient for low-risk internal tooling.
- Enhanced scanning is powered by Amazon Inspector, adds continuous rescanning (not just at push time), covers both OS and programming-language packages (npm, pip, Maven, Go modules, etc.), and layers in exploitability scoring. This is the tier most production workloads should run, and it's what people mean when they say "ECR enhanced scanning."
Enhanced scanning requires Amazon Inspector to be active in the account and incurs Inspector's per-image pricing, so budget accordingly before flipping the switch registry-wide.
Step 2: Enable AWS ECR Image Scanning at the Registry Level
Scanning configuration lives at the registry (account/region) level, not per-repository, when you want enhanced scanning applied broadly. Start by checking your current configuration:
aws ecr get-registry-scanning-configuration --region us-east-1
To turn on enhanced scanning for every repository in the registry:
aws ecr put-registry-scanning-configuration \
--region us-east-1 \
--scan-type ENHANCED \
--rules '[
{
"scanFrequency": "CONTINUOUS_SCAN",
"repositoryFilters": [
{ "filter": "*", "filterType": "WILDCARD" }
]
}
]'
If you'd rather scope enhanced scanning to specific repositories (recommended when rolling out gradually), replace the wildcard filter with an explicit repository name or prefix, e.g. "filter": "prod-*", "filterType": "WILDCARD".
For teams staying on basic scanning, the equivalent call is:
aws ecr put-registry-scanning-configuration \
--region us-east-1 \
--scan-type BASIC \
--rules '[]'
Step 3: Configure Scan-on-Push for New Repositories
Registry-level enhanced scanning with CONTINUOUS_SCAN already covers new pushes, but if you're running basic scanning or managing image scanning per repository, enable ECR scan on push explicitly when creating a repository:
aws ecr create-repository \
--repository-name my-app \
--image-scanning-configuration scanOnPush=true
For an existing repository:
aws ecr put-image-scanning-configuration \
--repository-name my-app \
--image-scanning-configuration scanOnPush=true
Scan-on-push means every docker push triggers an automatic scan without a manual aws ecr start-image-scan call — critical if you have multiple CI runners pushing images and can't guarantee someone remembers to kick off a scan manually.
Step 4: Set Up Continuous Rescanning with Enhanced Scanning
Vulnerability databases update daily; an image that was clean on Monday can be flagged Wednesday when a new CVE is published against a package it contains. Basic scanning only re-checks on push or manual trigger, so images sitting in the registry go stale. Enhanced scanning's CONTINUOUS_SCAN frequency (set in Step 2) automatically rescans images for 30 days after the last push, and Inspector re-evaluates findings as its intelligence feeds update — no re-push required. Confirm it's active per repository:
aws ecr describe-repositories --repository-names my-app \
--query 'repositories[0].imageScanningConfiguration'
Step 5: Automate Scanning in Your CI/CD Pipeline
Enabling the registry setting is necessary but not sufficient — your pipeline should also fail builds on scans that exceed your risk threshold rather than relying on someone checking the console. A minimal gate in a GitHub Actions or CodeBuild step:
docker push $ECR_REPO:$IMAGE_TAG
aws ecr wait image-scan-complete \
--repository-name my-app \
--image-id imageTag=$IMAGE_TAG
aws ecr describe-image-scan-findings \
--repository-name my-app \
--image-id imageTag=$IMAGE_TAG \
--query 'imageScanFindings.findingSeverityCounts'
Parse the severity counts and exit non-zero if CRITICAL or HIGH exceeds your policy — most teams start with "block on any CRITICAL, warn on HIGH" and tighten from there once noise is under control.
Step 6: Retrieve and Act on Scan Findings
Raw findings are only useful if someone triages them. Pull the full finding list for a deeper look at affected packages and fixed versions:
aws ecr describe-image-scan-findings \
--repository-name my-app \
--image-id imageTag=latest \
--output json
Each finding includes the CVE ID, severity, affected package/version, and (for enhanced scanning) an exploitability score plus a reference to whether a fix is available upstream. Route this output to your ticketing system or a centralized vulnerability dashboard rather than expecting engineers to poll the console — that hand-off is usually where ECR vulnerability scanning programs stall out after the initial rollout enthusiasm fades.
Troubleshooting and Verifying Your Setup
Scan shows "IN_PROGRESS" indefinitely. Enhanced scans can take several minutes for large images; if it never completes, check that Amazon Inspector is enabled in the account (aws inspector2 batch-get-account-status) — enhanced scanning silently fails to start without it.
put-registry-scanning-configuration returns AccessDeniedException. The calling role needs ecr:PutRegistryScanningConfiguration and, for enhanced scanning, inspector2:Enable. This is a registry-level action, so it also requires permissions beyond typical per-repository IAM policies.
Findings list is empty despite a vulnerable base image. Confirm the scan type actually applied to that repository — a wildcard filter set after the repository was created doesn't retroactively rescan existing images; push a new tag or trigger aws ecr start-image-scan manually.
Basic scan results look sparse compared to expectations. Basic scanning only checks OS-level packages via the Clair engine; it won't catch vulnerable application dependencies (npm, pip, etc.). That's expected — it's the main reason teams upgrade to enhanced scanning.
Verify end-to-end: push a known-vulnerable test image (e.g., an old alpine:3.10), confirm scan-on-push fires automatically, and check that describe-image-scan-findings returns non-zero critical/high counts within a few minutes. If that round-trip works, your AWS ECR image scanning pipeline is correctly wired.
How Safeguard Helps
Native ECR scanning tells you a CVE exists; it doesn't tell you whether that CVE is reachable in your running code, whether it duplicates a finding already suppressed elsewhere in your stack, or which of the fifty "critical" findings across your registries should actually get fixed today. Safeguard sits on top of your ECR scanning configuration — ingesting findings from basic and enhanced scans across every registry and account — and correlates them with reachability analysis, deployment context, and prior triage decisions so your team isn't re-litigating the same base-image CVE in every repository that inherited it. We also monitor scan-on-push and continuous-scan coverage across your registries, flagging repositories where scanning was silently disabled or misconfigured, and feed prioritized findings directly into the workflows your engineers already use. If you've enabled AWS ECR image scanning and are now drowning in the output, Safeguard is built for exactly that next problem.