AWS Elastic Container Registry offers two scanning modes: basic scanning powered by Clair and enhanced scanning powered by Amazon Inspector. The naming suggests one is simply better than the other, but the reality is more nuanced. Each has different coverage, different detection capabilities, and different blind spots.
Understanding these differences is the difference between actual container security and checking a compliance checkbox.
Basic Scanning
ECR basic scanning uses the open-source Clair scanner. It examines the OS packages installed in your container image and checks them against a database of known CVEs.
What Basic Scanning Covers
Basic scanning identifies vulnerabilities in operating system packages. For Debian-based images, it checks dpkg packages. For Alpine, it checks apk packages. For Red Hat-based images, it checks rpm packages.
It is triggered per-repository: you can configure scan-on-push for specific repositories. Results appear in the ECR console and are available through the DescribeImageScanFindings API.
What Basic Scanning Misses
Application-level dependencies are invisible to basic scanning. Your Python pip packages, Node.js npm modules, Java JARs, Go modules, and Rust crates are not scanned. If your application has a critical vulnerability in a third-party library, basic scanning will not find it.
Language-specific package managers are not recognized. A Go binary with a vulnerable version of a dependency will show zero findings in basic scanning because the scanner only understands OS package managers.
Binaries without package metadata are also missed. If you copy a compiled binary into your image without installing it through a package manager, basic scanning has no way to identify what it is or whether it is vulnerable.
Scan Frequency Limitations
Basic scanning runs once on push and can be triggered manually, but it does not automatically rescan images when new vulnerabilities are disclosed. An image scanned on Monday might have critical vulnerabilities published on Tuesday that basic scanning will not find until you manually trigger a rescan.
Enhanced Scanning
Enhanced scanning leverages Amazon Inspector, which provides continuous, automated scanning with broader coverage.
What Enhanced Scanning Adds
Programming language package scanning: Inspector identifies vulnerabilities in Python, Node.js, Java, .NET, Ruby, Rust, and Go dependencies. This is the critical gap that basic scanning misses.
Continuous rescanning: Inspector automatically rescans images when new vulnerabilities are added to its database. You do not need to trigger rescans manually. When a new CVE is published, Inspector re-evaluates all your images and updates findings within hours.
Network reachability analysis: For running containers, Inspector can analyze network exposure and prioritize vulnerabilities that are reachable from the network versus those in code paths that are not network-accessible.
Coverage Limitations of Enhanced Scanning
Enhanced scanning uses Inspector's vulnerability database, which aggregates data from multiple sources including NVD, distribution security advisories, and language-specific advisory databases. But no scanner catches everything.
Custom or uncommon packages may not be in Inspector's database. If you build internal libraries or use niche packages that are not tracked by common vulnerability databases, Inspector cannot assess them.
False positives remain an issue. Inspector may flag a CVE in a package version that your image contains, but the vulnerable code path may not be reachable in your configuration. Inspector's enhanced scanning includes some reachability analysis, but it is not comprehensive.
Scan depth varies by language ecosystem. Inspector's coverage of Python and Node.js packages is strong. Coverage for Rust crates and Go modules has improved but may not match the accuracy of purpose-built scanners for those ecosystems.
Configuring ECR Scanning Effectively
Enable Enhanced Scanning for All Repositories
If you are paying for Inspector, enable enhanced scanning for all ECR repositories. The continuous rescanning alone justifies the cost compared to point-in-time basic scanning.
Configure enhanced scanning at the registry level under ECR settings. Select "Enhanced scanning" and specify which repositories to include. Use filter rules to cover all repositories:
{
"rules": [
{
"repositoryFilters": [
{
"filter": "*",
"filterType": "WILDCARD"
}
],
"scanFrequency": "CONTINUOUS_SCAN"
}
]
}
Integrate Findings With Security Hub
ECR scan findings automatically flow to AWS Security Hub when enhanced scanning is enabled. This provides a centralized view of container vulnerabilities alongside other AWS security findings.
Configure Security Hub automations to create tickets, send notifications, or trigger remediation workflows when critical container vulnerabilities are detected.
Use EventBridge for Automation
ECR publishes scan finding events to EventBridge. Create rules that trigger Lambda functions or Step Functions workflows when vulnerabilities above a certain severity are found. For example, automatically block deployment of images with critical findings.
Set Image Lifecycle Policies
Combine scanning with lifecycle policies to automatically remove old, unpatched images. A policy that deletes images older than 90 days ensures that stale, vulnerable images are not available for deployment.
Beyond ECR Scanning
ECR scanning, even in enhanced mode, is one piece of the puzzle. It checks for known vulnerabilities in recognized packages. It does not verify image provenance, validate build integrity, or assess configuration risks.
Complement With Admission Control
Use an admission controller in your EKS cluster to enforce that only images from your ECR registry, with scan findings below a severity threshold, are allowed to run. AWS provides the Amazon EKS Pod Identity and IAM Roles for Service Accounts to restrict which pods can pull from which repositories.
Add SBOM Generation
ECR scanning tells you what is vulnerable. SBOMs tell you what is in the image. Generate SBOMs during your build pipeline and store them alongside your images as OCI artifacts. This provides a complete inventory for incident response and compliance.
Layer in Runtime Monitoring
Static scanning finds known vulnerabilities. Runtime monitoring finds actual exploitation. Deploy runtime security tools that watch for suspicious process execution, unexpected network connections, and filesystem modifications in your running containers.
How Safeguard.sh Helps
Safeguard.sh provides container scanning that complements and extends AWS ECR's capabilities. It generates comprehensive SBOMs for every image, scans across language ecosystems with accuracy that matches purpose-built tools, and provides continuous monitoring with faster vulnerability database updates. When ECR scanning shows you findings, Safeguard.sh shows you the full context: which applications use the vulnerable component, what the dependency chain looks like, and what the actual risk is to your organization.