AWS ECR Security for SOC 2: Image Scanning and Repository Policies
How to configure Amazon ECR for SOC 2 compliance — image scanning on push, tag immutability, repository policies, and how to use ECR data as CC7.1 evidence.
ECR Security for SOC 2
Amazon Elastic Container Registry (ECR) stores your Docker container images. For teams running ECS, EKS, or Lambda container functions, ECR is a critical part of the SOC 2 surface area. The SOC 2 requirements that apply: you need to scan images for vulnerabilities (CC7.1/CC7.5) and ensure image integrity through immutable tags (CC6.8 — preventing unauthorized modification).
SecureSpect checks three ECR conditions:
aws.ecr.scan_on_push — CC7.1
Verifies image scanning is enabled on push for all ECR repositories.
aws.ecr.tag_immutability — CC6.8
Verifies tag immutability is enabled — prevents overwriting image tags.
aws.ecr.repository_policy — CC6.1
Checks that repository policies don't grant cross-account access
without explicit justification.
Enabling Image Scanning on Push
ECR Enhanced Scanning (using Amazon Inspector under the hood) is the preferred configuration for SOC 2 because it provides continuous rescanning as new CVEs are published, not just a one-time scan on push.
Enable Enhanced Scanning for your registry:
# Enable Enhanced Scanning for all repositories in the registry
aws ecr put-registry-scanning-configuration --scan-type ENHANCED --rules '[{"repositoryFilters":[{"filter":"*","filterType":"WILDCARD"}],"scanFrequency":"CONTINUOUS_SCAN"}]'
For Basic Scanning (simpler, but only scans on push):
# Enable scan on push for a specific repository
aws ecr put-image-scanning-configuration --repository-name your-repo-name --image-scanning-configuration scanOnPush=true
For SOC 2, Enhanced Scanning is preferred because auditors want to see that vulnerability scanning is continuous, not just at build time.
Tag Immutability
Tag immutability prevents overwriting an existing image tag. Without it, someone could push a new (potentially malicious) image under the same tag as a known-good image. Enabling immutability means tags can only be used once — a critical supply chain security control.
# Enable tag immutability for a repository
aws ecr put-image-tag-mutability --repository-name your-repo-name --image-tag-mutability IMMUTABLE
Once enabled, pushing an image with an existing tag will fail. This forces the use of content-addressed tags (image digest or versioned semantic version tags).
Integrating ECR Scanning into CI/CD for SOC 2
For SOC 2, the strongest evidence is not just that scanning is enabled — it's that your pipeline blocks on critical findings.
Example GitHub Actions step to fail on critical CVEs:
- name: Check ECR scan results
run: |
aws ecr wait image-scan-complete --repository-name $REPO_NAME --image-id imageTag=$IMAGE_TAG
CRITICAL=$(aws ecr describe-image-scan-findings --repository-name $REPO_NAME --image-id imageTag=$IMAGE_TAG --query 'imageScanFindings.findingSeverityCounts.CRITICAL' --output text)
if [ "$CRITICAL" != "None" ] && [ "$CRITICAL" -gt 0 ]; then
echo "FAILED: $CRITICAL critical vulnerabilities found"
exit 1
fi
This pipeline enforcement, documented and shown to auditors, is strong CC7.5 evidence.
ECR Repository Policies
Repository policies control who can push and pull images. For SOC 2 CC6.1, verify that:
- No repository allows unauthenticated pulls (public repositories should be intentional)
- Cross-account access is restricted to documented, justified accounts
- Wildcard principal (
*) is not used in repository policies
# Check repository policy
aws ecr get-repository-policy --repository-name your-repo-name
FAQ
Do I need Enhanced Scanning or is Basic Scanning enough? Basic Scanning satisfies the minimum. Enhanced Scanning is better because it continuously rescans as new CVEs emerge — which maps more directly to CC7.5 (addressing vulnerabilities as they're discovered).
What should I do about critical CVEs in base images? Rebuild with an updated base image. For operating system-level CVEs, pin to a patched OS version. Document the timeline from discovery to remediation in your vulnerability management log.
Does ECR scanning replace GitHub Dependabot? No. ECR scans OS packages and libraries bundled in the container. Dependabot scans your application dependencies (package.json, requirements.txt). You need both.