re:Invent 2025 - Enhancing Container Security with Amazon ECR

Container images do not stay static. An image that passes a security check when built can develop issues as new vulnerabilities are disclosed against its dependencies, and teams running hundreds or thousands of images need a systematic way to track which images are affected and precisely where they are running. In this post, we'll explore how Amazon Elastic Container Registry (ECR) connects with a range of AWS services to give you a security layer that spans the full container supply chain. The session insights come from Liz Duke, Principal GTM Specialist SA for Containers at AWS, who presented CNS208 at AWS re:Invent 2025.

Automating the container supply chain

A container supply chain covers each step from code to production: the code repository, the build process that assembles images from multiple layers, the registry where those images are stored, and the orchestrator that pulls and runs them. Monitoring containers during runtime extends this chain to its logical conclusion. Security needs to be present at each stage, not only at the point of image build, because issues introduced or discovered at one stage propagate into every stage that follows.

Full automation is the most direct path to consistent security coverage. When humans carry out steps manually, checks get skipped and processes drift over time. AWS CodePipeline gives you a way to automate the entire journey from code commit to deployment. It integrates with AWS Identity and Access Management (IAM) throughout, so each stage operates with the minimum permissions it needs and no individual has standing access to carry out privileged operations on demand. When a developer pushes code to a Git repository, CodePipeline picks up the event and retrieves the code using a temporary access token. AWS CodeBuild then assembles the container image from its constituent layers: a base OS image, your application code, libraries, and dependencies.

Each of these layers is a potential source of security issues. Base OS images carry their own vulnerability histories. Open source libraries introduce dependencies that may not be immediately visible. Application code adds further surface area. When you are managing a small number of images, tracking this manually is feasible. When you are managing hundreds or thousands, finding a problem across that inventory is like finding a needle in a haystack, and doing so continuously as new CVEs are published is a continuous operational burden. This is why point-in-time scanning at build time is necessary but not sufficient on its own, and why the model needs to extend to ongoing monitoring throughout the image lifecycle.

At the build stage, AWS Signer gives you the option to sign images, creating a cryptographic record of each image's state at the point it was approved. If the image is modified after signing, that modification can be detected before deployment. Previously, integrating AWS Signer into a container pipeline required each team to build and maintain the integration independently, which created inconsistency across an organization and added repeated implementation work with every new pipeline.

Amazon ECR: storage, access control, and scanning

Amazon ECR is a fully managed container registry. Each AWS account includes a private ECR registry that supports Docker images, Open Container Initiative (OCI) images, and other OCI-compatible artifacts. Images are transferred over HTTPS and encrypted at rest using AES-256 with an AWS-owned key, at no extra charge. Customers who need to manage their own encryption keys can supply an AWS Key Management Service (KMS) key instead.

Amazon ECR uses IAM to control push and pull access separately at the repository level. These are distinct concerns worth treating independently. Restricting push access matters because when developers push images directly to a repository, bypassing your pipeline, they also bypass the security checks built into that pipeline. Restricting pull access matters because container images frequently carry proprietary application code, business logic, and configuration that organizations need to protect. Getting these permissions right is one of the most impactful configuration decisions you can make for your registry.

Private VPC endpoints route traffic between your compute environment and the registry within the Amazon network. Images never traverse the public internet, and you may not need a NAT gateway or internet gateway solely to support image pulls from within a VPC. Amazon ECR also supports pull-through cache, which lets you connect to an upstream registry and cache images locally in your ECR registry, keeping them updated automatically. This gives you a single, controlled location for third-party images rather than pulling directly from external sources on demand.

Lifecycle policies let you define rules that automatically remove old images on a schedule you control. When you are managing thousands of images, this is not only a storage consideration. Stale images in a registry represent ongoing scanning surface area and a potential source of unintended pulls. Automated cleanup keeps your repositories focused on images you are actively using, and reduces the operational cost of reviewing findings for images that are no longer relevant.

Amazon ECR offers two scanning modes. The default is Amazon's native basic scanning, which runs automatically when you push an image and checks against known CVEs (Common Vulnerabilities and Exposures). Results appear in the ECR console, and the scanner covers a broad range of operating systems. For deeper coverage, enhanced scanning integrates ECR with Amazon Inspector. Where basic scanning covers OS-level findings, Inspector adds coverage for application package dependencies, significantly expanding what gets examined. Inspector also handles image types that basic scanning cannot cover, including scratch-built images, distroless images, and Chainguard images.

Inspector prioritizes its findings based on factors such as available remediations, publicly known exploitation status, and whether software has passed its support lifecycle. It sends results to AWS Security Hub, creating a centralized audit trail for compliance reporting. Enhanced scanning also supports continuous scanning: after you push an image, it remains under active evaluation. When new CVEs are added to the Inspector database, your existing images are re-evaluated against them. The integration between ECR, Inspector, Amazon ECS (Elastic Container Service), and Amazon EKS (Elastic Kubernetes Service) extends this by reporting not just which images have findings, but which clusters are running those images, down to the task and pod level. This means you can prioritize remediation based on what is active in production rather than working through a flat list with no operational context.

Image signing enforcement and runtime monitoring

Scanning tells you what was inside an image at a point in time. Signing tells you whether the image you are deploying is the same one that passed your security checks. These are complementary properties. An image could pass scanning and subsequently be modified before reaching your cluster, and scanning cannot detect that. Code signing is the mechanism that closes this gap, and it is an established industry standard for exactly this reason.

Amazon ECR now includes fully managed container image signing with AWS Signer as a native, centralized feature, launched at re:Invent 2025. Enabling it requires a few clicks in the console or a single CLI command. There is no longer a need to build and maintain an AWS Signer integration inside each individual pipeline. ECR stores signatures alongside the images themselves, so the verification record is co-located with the artifact it covers and travels with it through the registry.

Enforcing signature checks at deployment time completes the supply chain. On Amazon EKS, policy enforcement tools such as Gatekeeper with Ratify, or Kyverno, check an image's signature during the admission process and can block images whose signatures do not match the approved version before they are scheduled on the cluster. On Amazon ECS, lifecycle hooks combined with AWS Lambda provide the same capability. You can configure enforcement to either block images with non-matching signatures from running, or permit them while generating an alert for investigation. The appropriate choice depends on your operational context and tolerance for disruption, but introducing the check at deployment time addresses a gap that scanning alone cannot cover.

Once containers are running, Amazon GuardDuty provides runtime behavioral monitoring for Amazon ECS and Amazon EKS workloads. Rather than inspecting image contents, GuardDuty observes what running containers actually do. It surfaces behavioral signals such as containers connecting to known command-and-control server addresses, unusual data egress patterns that suggest data exfiltration, and compute behavior inconsistent with the container's intended function (such as cryptocurrency mining on infrastructure not provisioned for it). You can enable GuardDuty across your clusters or selectively for specific ones, on both Amazon ECS and Amazon EKS.

Container security requires controls distributed across the full supply chain: in the pipeline when images are assembled, in the registry where they are stored, at deployment when they go live, and during runtime when they serve traffic. Amazon ECR, Amazon Inspector, AWS Signer, and Amazon GuardDuty give you the tools to cover each of these stages without slowing your delivery teams. Your security posture needs to keep evolving as the vulnerability landscape changes, and the combination of continuous scanning, lifecycle policies, centralized signing, and runtime monitoring gives you the means to do that.

Watch the full session: AWS re:Invent 2025 - Enhancing container security with Amazon ECR (CNS208)