What is AWS container scanning?

Understanding AWS container scanning capabilities

AWS container scanning is the practice of identifying security issues in your software containers before they run in production. This process analyzes the different layers of a container image, including the base operating system, dependencies, and configuration files. It checks these components against CVE (Common Vulnerabilities and Exposures) databases including the National Vulnerability Database (NVD) and vendor-specific feeds to identify known vulnerabilities and weaknesses.

It is important to understand the difference between scanning container images and scanning running containers. Scanning images analyzes files and packages at rest in the registry (static analysis). Assessing running containers evaluates installed packages and configuration in active workloads (runtime vulnerability assessment). Separate runtime threat detection tools monitor behavior like process execution, network connections, and file access for signs of active attacks. AWS native services scan both images at rest in Amazon ECR and running containers on Amazon ECS, Amazon EKS, and AWS Fargate for software vulnerabilities via Amazon Inspector. You may still need additional tools for runtime threat detection (behavioral monitoring of process execution, network connections, and file access) and broader context like network exposure or IAM permissions.

Container Security Best Practices [Cheat Sheet]

Use this cheat sheet as a quick reference to ensure you have the proper benchmarks in place to secure your container environments.

あなたの仕事のメールはこちら

Download

AWS container scanning tools and options

Amazon ECR image scanning

Amazon Elastic Container Registry (ECR) offers two scanning options: basic scanning and enhanced scanning. Basic scanning uses the open-source project Clair to check images for vulnerabilities and runs automatically on image push. You can also trigger scans on demand for specific images already stored in ECR. Continuous rescanning of stored images requires enhanced scanning with Amazon Inspector.

Enhanced scanning is powered by Amazon Inspector and offers significant advantages, including support for scratch, distroless, and Chainguard base images (announced March 2025). It provides continuous rescanning, supports a wider range of operating systems, and integrates findings directly with AWS Security Hub and other AWS security services. However, keep in mind that ECR's at-rest scanning only works for images stored in ECR repositories. Once deployed to ECS, EKS, or Fargate, Amazon Inspector can assess running containers for vulnerabilities regardless of the source registry.

Amazon Inspector for container scanning

Amazon Inspector scans images stored in ECR and assesses running containers on Amazon ECS, Amazon EKS, and AWS Fargate for software vulnerabilities. For runtime assessment, Inspector deploys components (SSM Agent for ECS/EC2, or integrates with EKS add-ons) to collect package inventory and configuration data from active workloads. This provides continuous vulnerability assessment but does not include behavioral threat detection like monitoring process execution or network anomalies.

Inspector now maps ECR images to specific ECS tasks and EKS pods (announced May 2025), correlating vulnerabilities found in an image with the exact active containers using that image. This helps you understand which running applications are affected by a specific security flaw and prioritize fixes based on actual deployment. Pricing for Amazon Inspector is based on the number of container images assessed (charged per initial scan and rescan) and the volume of running container assessments (charged per container instance per month for ECS, EKS, and Fargate workloads).

Third-party container scanning solutions

Many organizations use third-party solutions to supplement AWS native tools. Native tools often lack deep cross-cloud context and advanced prioritization across network exposure, IAM permissions, and data sensitivity. For example, correlating a vulnerable workload with an internet-exposed service account and reachable sensitive data requires shared code-to-cloud context that spans multiple AWS services and security domains. Third-party tools generally fall into categories like Cloud-Native Application Protection Platforms (CNAPP), specialized container security tools, and open-source scanners. These tools typically integrate with your AWS environment through APIs to pull data and analyze your security posture.

How AWS container scanning works

The container scanning lifecycle

The container scanning lifecycle consists of three main phases: pre-deployment scanning, registry scanning, and runtime monitoring. During the pre-deployment phase, images are scanned automatically as part of the CI/CD pipeline build process.

Registry scanning occurs when these images are pushed to a storage location like ECR. Finally, runtime scanning monitors the containers after they have been deployed to detect any issues that arise during operation.

Vulnerability detection and databases

Scanners work by comparing the contents of a container image against a Common Vulnerabilities and Exposures (CVE) database. These databases are compiled from feeds provided by the National Vulnerability Database (NVD), software vendors, and security researchers.

The scanner identifies vulnerable packages, libraries, and operating system components present in your image. A major challenge is dealing with false positives and the lag between disclosure and database updates (often 24-72 hours for NVD). Architecture differences also affect detection and remediation—for example, a CVE fix available for AMD64 images may not yet exist for ARM64 variants, and distro-specific packages (Alpine vs. Debian) require different remediation paths.

Scan results and findings management

A typical scan output lists the severity of vulnerabilities found, the specific packages affected, and guidance on how to fix them. Findings are usually categorized by CVSS scores, which is a standard system for rating the severity of security flaws.

You can integrate these results with AWS Security Hub to manage findings in one central location. However, managing a high volume of scan results without context can be overwhelming for security teams.

Take the 10-Minute Wiz Container Security Tour

In this short interactive tour, you’ll follow a real-world scenario where Wiz identifies exposed containers, visualizes the full attack path, and fixes the issue directly in code—all within minutes.

もっと読む

Security benefits and risk reduction

Scanning can prevent the deployment of vulnerable images when you enforce policy gates in CI/CD pipelines or registries. For example, you can configure your build pipeline to fail when images contain critical or high-severity CVEs, or use Kubernetes admission controllers (OPA Gatekeeper, Kyverno) to block non-compliant images from running in EKS clusters. This practice helps you meet compliance requirements for regulations that mandate strict vulnerability management. Continuous scanning is also vital for catching newly disclosed vulnerabilities in images that have already been deployed.

Supply chain security: Container scanning detects vulnerabilities in base images and third-party dependencies, but comprehensive supply chain security requires additional practices:

Generate SBOMs: Use Syft (or Docker’s SBOM support) to generate a Software Bill of Materials during the build. Store the SBOM either attached to the image in ECR as an OCI artifact or in an external artifact store like S3, ideally referenced by image digest.

Sign images: Use Sigstore cosign to sign container images after they pass vulnerability scans and policy checks. This provides cryptographic proof the image hasn’t been modified between approval and deployment (prefer signing the digest, not just the tag).

Verify signatures: Enforce signature verification at deploy time using Kubernetes admission controls (e.g., Kyverno or Gatekeeper/OPA with cosign integration). Only allow pods to run images that are signed by trusted keys/identities, preventing unsigned or tampered images from executing.

Track provenance: Use in-toto attestations to record the complete build process (source commit, build environment, scan results, approvals). This creates an auditable chain from source code to running container.

Compliance mapping: Container scanning directly supports vulnerability management requirements across multiple frameworks:

• NIST SP 800-53: Satisfies RA-5 (Vulnerability Monitoring and Scanning) and SI-2 (Flaw Remediation) by providing continuous vulnerability assessment and documented remediation tracking.

• PCI DSS 4.0: Addresses Requirement 6.3.2 (inventory of bespoke and custom software) and 6.3.3 (vulnerabilities identified and addressed) by scanning container images before deployment and maintaining scan records.

• ISO 27001:2022: Supports A.8.8 (management of technical vulnerabilities) and A.5.23 (information security for use of cloud services) through documented vulnerability assessment processes.

• CIS Benchmarks: Aligns with CIS Docker Benchmark 4.5 (ensure Content trust for Docker is Enabled) and CIS Kubernetes Benchmark 5.4.1 (prefer using secrets as files over secrets as environment variables) when combined with secrets scanning.

• SOC 2 Type II: Provides evidence for CC7.1 (system monitoring) and CC7.2 (system vulnerability detection) through continuous scanning logs and remediation tracking.

• Audit evidence: Export Inspector findings to S3 for long-term retention (7 years for PCI DSS, 3 years for SOC 2). Use AWS Security Hub custom insights to generate compliance reports showing vulnerability trends, mean time to remediation, and coverage percentages.

Implementation challenges and best practices

Common scanning challenges

Alert fatigue is a major issue, as scanners often produce a high volume of findings with little context. Prioritizing thousands of CVEs without knowing if they are actually exploitable in your runtime environment is difficult.

• Integration complexity: Connecting multiple AWS services and third-party tools can be technically difficult.

• Ephemeral containers: Scanning short-lived workloads that spin up and down quickly is challenging, especially when 60% of containers live for one minute or less according to Sysdig's 2025 Cloud-Native Security and Usage Report. This requires continuous runtime assessment rather than periodic scans.

• Coverage gaps: At-rest scanning is limited to images stored in ECR repositories. However, once deployed to Amazon ECS, Amazon EKS, or AWS Fargate, Amazon Inspector can assess running containers for vulnerabilities regardless of the source registry (Docker Hub, Quay.io, private registries).

Best practices for AWS container scanning

You should scan at multiple stages, including build time, in the registry, and during runtime.

CI/CD enforcement: Implement automated scanning gates in your CI/CD pipelines to block risky images before deployment:

Build-time gates: Configure your CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins) to fail builds when ECR scan results contain vulnerabilities above your threshold.

Admission control: Use Kubernetes admission controllers to prevent non-compliant images from running in EKS.

Pre-deployment checks: Configure ECR image scanning to run automatically on push, then use AWS Lambda to check scan results before updating ECS task definitions or EKS deployments. Block updates if findings exceed your threshold.

• Severity thresholds: Establish clear rules for what severity level requires immediate action.

• Base image hygiene: Regularly update base images and use minimal images to reduce the attack surface. This is particularly important as container image sizes have quintupled according to Sysdig's 2025 report, expanding the number of packages and potential vulnerabilities in each image.

• Remediation tracking: Integrate scan results with ticketing systems to ensure issues are assigned and fixed.

Wizアカデミー

AWSセキュリティベストプラクティス：10ステップで環境を健康診断

クラウド環境を守り、リスクを軽減し、コンプライアンスを容易に確保するための必須のAWSセキュリティベストプラクティスをご紹介します。

もっと読む

When AWS native scanning isn't enough

Native scanning often lacks the broader cloud context needed to fully understand risk. These tools may not see network exposure, permissions, or access to sensitive data. This makes it hard to correlate a container vulnerability with its actual exploitability in your specific environment.

Organizations with multi-cloud environments need cross-cloud visibility that native AWS tools cannot provide. Native scanning also does not trace vulnerabilities back to the specific source code or developer responsible. This creates a gap between identifying a vulnerability and understanding if it poses a real business risk.

How Wiz transforms AWS container security beyond basic scanning

Wiz provides agentless scanning across Amazon ECR, EKS, ECS, and Fargate without impacting performance. By unifying image, runtime, identity, and network context in the Wiz Security Graph, teams can see real attack paths instead of triaging isolated CVEs. This shifts security from managing vulnerability lists to understanding and blocking actual risk.

The Wiz Security Graph correlates container vulnerabilities with network exposure, IAM permissions, and sensitive data to show true risk.

• Code-to-cloud tracing: Trace a vulnerable package from a running container back to the source repository, specific commit, and owning team to speed targeted fixes. This eliminates the manual work of correlating runtime findings with code ownership, reducing mean time to remediation from days to hours.

• WizOS: This hardened base image acts as an alternative that eliminates vulnerability noise at the source.

• Runtime validation: Wiz Defend's eBPF sensor observes runtime behavior and execution context to help validate exploitability and reduce noise. For example, if a vulnerable library is present but never loaded or executed, Wiz can deprioritize that finding based on actual runtime evidence.

• Attack path analysis: This feature identifies toxic combinations where container vulnerabilities combine with misconfigurations to create critical risks.

Wiz prioritizes the small subset of container vulnerabilities that form real attack paths when combined with network exposure, IAM permissions, and access to sensitive data. For example, a medium-severity CVE in a container with no network exposure and read-only permissions generates less urgency than the same CVE in an internet-facing container with admin credentials.

Ready to move beyond basic vulnerability lists to contextual container risk management? Get a demo to see how Wiz prioritizes the container vulnerabilities that actually threaten your AWS environment.