AWS Elastic Container Registry offers built-in vulnerability scanning for container images. Most teams enable it, see some results, and assume they are covered. They are not. The default scanning configuration misses entire categories of vulnerabilities, does not cover all your images, and provides no mechanism for automated remediation.
This guide walks through what ECR scanning actually does, where it falls short, and how to build a scanning strategy that provides real security value.
Two Scanning Modes, Very Different Capabilities
ECR offers two scanning modes: basic scanning and enhanced scanning. The difference between them is substantial, and understanding it is critical to building an effective strategy.
Basic Scanning
Basic scanning uses the open-source Clair project under the hood. It scans images on push and checks OS package vulnerabilities against a database derived from upstream Linux distribution security advisories.
What basic scanning catches: known CVEs in OS packages like openssl, curl, glibc, and other packages installed via apt, yum, or apk.
What basic scanning misses: application-level dependencies. If your Node.js application has a vulnerable version of lodash or your Python app depends on a compromised requests library, basic scanning will not find it. It only sees OS packages.
Basic scanning also only runs on push. If a new CVE is published tomorrow for a package in an image you pushed last month, basic scanning will not flag it. The image sits in your registry, quietly vulnerable, until someone pushes a new version.
Enhanced Scanning
Enhanced scanning, powered by Amazon Inspector, is a significant upgrade. It scans OS packages and application dependencies (Node.js, Python, Java, Go, Ruby, .NET, and Rust). It runs continuously, re-evaluating images as new vulnerabilities are disclosed.
Enhanced scanning also provides richer finding data, including CVSS scores, exploit availability, and remediation guidance. It integrates with Security Hub for centralized finding management.
Use enhanced scanning. Basic scanning is better than nothing, but enhanced scanning is what you need for production workloads. The cost is based on the number of images scanned, and for most organizations it is negligible compared to the security value.
Configuring Scanning Correctly
Enabling enhanced scanning is step one. Configuring it correctly is step two, and it is where most teams stumble.
Enable continuous scanning, not just scan-on-push. Enhanced scanning supports continuous scanning, which re-evaluates images as new CVEs are published. This is essential. A clean scan result today does not mean the image is clean tomorrow.
Configure scan filters. Enhanced scanning lets you define which repositories get scanned using filter rules. At minimum, scan all repositories that contain images deployed to staging and production. Scanning every repository including scratch and experimental ones adds noise without proportional security value.
Set up EventBridge rules for findings. Enhanced scanning publishes findings to EventBridge. Create rules that route critical and high severity findings to your alerting system. A critical CVE in a production image should not wait until someone checks the ECR console.
Understanding Scan Results
ECR scan findings include a severity rating, but the severity alone does not tell you what to do.
Context matters more than severity. A critical CVE in a library that your application does not actually use at runtime is less urgent than a medium CVE in a library that handles user input. Unfortunately, ECR scanning does not provide this runtime context. You need additional tooling or manual analysis to assess true exploitability.
Check exploit availability. Enhanced scanning findings include information about whether a public exploit exists. Prioritize vulnerabilities with known exploits -- they are the ones that attackers will use first.
Understand the fix status. Some vulnerabilities have fixes available in newer package versions. Others do not. Your remediation priority should account for whether a fix exists. Spending time investigating a vulnerability with no fix available is less productive than patching one where an update is ready.
Filter out noise. Not every finding is actionable. Some CVEs affect functionality you do not use. Some are disputed. Build a process for triaging findings and marking false positives so your team focuses on real risks.
Building an Automated Scanning Pipeline
Manual scanning and manual result review do not scale. Here is how to automate the pipeline.
Scan in CI/CD before pushing to ECR. Use Trivy, Grype, or Snyk in your CodeBuild or GitHub Actions workflow to scan images before they reach ECR. This catches vulnerabilities early, when they are cheapest to fix. Fail the build if the image exceeds your severity threshold.
Use ECR enhanced scanning as the second layer. Even with CI/CD scanning, enable ECR enhanced scanning for continuous monitoring. New CVEs are published daily, and your CI/CD scan only catches what was known at build time.
Automate finding routing. Use EventBridge rules and Lambda functions to automatically create tickets, send Slack notifications, or trigger remediation workflows based on finding severity and affected repository.
Implement image lifecycle policies. ECR lifecycle policies can automatically delete old, unpatched images. Define policies that keep only the most recent N images or images newer than a specific date. Old images accumulate vulnerability findings and increase your attack surface.
Multi-Account Scanning Strategy
Most organizations use multiple AWS accounts -- development, staging, production, shared services. Your scanning strategy needs to cover all of them.
Enable enhanced scanning in every account. Each account with ECR repositories needs enhanced scanning enabled. There is no way to scan images in one account from another.
Centralize findings in Security Hub. Use Security Hub's cross-account aggregation to collect scanning findings from all accounts into a single view. This gives your security team a unified dashboard without needing to switch between accounts.
Standardize scanning configuration. Use AWS Organizations SCPs and CloudFormation StackSets to enforce consistent scanning configuration across all accounts. You do not want to discover during an incident that your production account's scanning was accidentally disabled.
ECR Image Signing and Verification
Scanning tells you whether an image has known vulnerabilities. Signing tells you whether the image came from a trusted source. Both are necessary.
Sign images after scanning. After an image passes your vulnerability scan, sign it using AWS Signer with Notation or cosign. The signature attests that the image was built by your CI/CD pipeline and passed your security checks.
Verify signatures before deployment. Configure your ECS task definitions or EKS admission controllers to verify image signatures before allowing deployment. An unsigned or invalidly signed image should be rejected.
Store signatures in ECR. Both Notation and cosign can store signatures as OCI artifacts in ECR alongside the images they sign. This keeps the signature lifecycle tied to the image lifecycle.
Handling Base Image Vulnerabilities
Base image vulnerabilities account for the majority of findings in most organizations. A single vulnerable package in ubuntu:22.04 shows up in every image that uses it as a base.
Track base image usage. Know which base images your organization uses and which application images derive from each one. When a base image vulnerability is disclosed, you need to quickly identify all affected downstream images.
Use minimal base images. Distroless images, Alpine-based images, and scratch-based images have dramatically fewer packages and therefore fewer vulnerabilities. A typical ubuntu:22.04 base has hundreds of packages. A distroless base has a handful.
Automate base image updates. When a patched base image is available, automatically trigger rebuilds of downstream application images. Tools like Dependabot and Renovate can automate this for Dockerfiles.
Compliance and Reporting
Scanning data feeds into compliance requirements for standards like SOC 2, FedRAMP, and PCI DSS.
Generate regular scanning reports. Export scanning findings to S3 or a data warehouse for historical tracking. Compliance auditors want to see trends over time, not just a point-in-time snapshot.
Track mean time to remediate. Measure how long it takes your team to patch vulnerabilities from discovery to deployment. This metric drives improvement and satisfies auditor questions about your vulnerability management process.
Document your scanning policy. Write down what you scan, how often, what your severity thresholds are, and what your remediation SLAs look like. This document is what auditors actually want to see.
How Safeguard.sh Helps
Safeguard.sh augments ECR scanning with deeper analysis, better prioritization, and cross-registry visibility. It correlates ECR findings with runtime context to tell you not just which images are vulnerable, but which vulnerable images are actually running in production and processing customer data.
The platform generates SBOMs for every image in your ECR repositories, tracks dependency changes over time, and provides a prioritized remediation queue that accounts for exploit availability, deployment context, and business criticality. Instead of drowning in thousands of ECR findings, you get a focused list of what actually matters.