Container Image Security: Scanning, Signing, and Runtime Protection Across Clouds

Container Security Is a Pipeline Problem, Not a Runtime Problem

Most container security strategies are backwards. Teams deploy containers to production, then run a scanner against running containers, then open tickets to fix the vulnerabilities found. By the time those tickets are prioritized, triaged, and fixed, the vulnerable containers have been running in production for weeks. Meanwhile, the same base image with the same vulnerabilities is being used to build new images every day.

The correct approach is to shift security left into the build pipeline. Scan images before they are pushed to the registry. Block vulnerable images from being deployed. Sign images that pass scanning so the runtime environment can verify provenance. And generate SBOMs (Software Bills of Materials) so you can respond to the next Log4Shell-style vulnerability in hours instead of weeks.

This guide covers the full container security lifecycle across AWS, Azure, and GCP -- from image scanning and signing in CI/CD to registry policies and runtime protection.

Image Scanning: What Each Cloud Offers

AWS ECR Image Scanning

ECR offers two scanning modes: Basic scanning (powered by Clair, free) and Enhanced scanning (powered by Amazon Inspector, paid). Basic scanning checks for CVEs in OS packages when you push an image or trigger a manual scan. Enhanced scanning adds programming language package scanning (npm, pip, Maven, Go modules), continuous scanning that re-evaluates images when new CVEs are published, and integration with AWS Security Hub for centralized findings.

The reality: Basic scanning is better than nothing but misses a significant class of vulnerabilities. It only checks OS packages -- if your Node.js application has a vulnerable npm dependency, Basic scanning will not find it. Enhanced scanning with Inspector costs $0.09 per image scan for the first 50,000 scans per month, which adds up quickly if you build frequently. For a team pushing 100 images per day, that is about $270 per month.

My recommendation: Use Enhanced scanning for production registries and Basic scanning for development registries. Set up ECR lifecycle policies to automatically delete untagged images and images older than 30 days in development, which reduces your scan surface and registry costs.

Azure Container Registry with Defender for Containers

ACR integrates with Microsoft Defender for Containers, which provides vulnerability scanning powered by Qualys. When you push an image to ACR, Defender scans it automatically. Findings appear in the Azure Security Center with severity ratings and remediation guidance.

Pricing: Defender for Containers costs approximately $7 per vCPU per month for the runtime protection component, plus a per-scan cost for registry scanning. For a cluster with 20 vCPUs, that is about $140 per month. The scanning itself is included in the Defender plan -- there is no separate per-image charge.

What I like: Defender for Containers goes beyond registry scanning. It monitors running containers for suspicious behavior -- privilege escalation, cryptomining processes, anomalous network connections. This is genuine runtime protection, not just vulnerability scanning. The integration with Azure Policy lets you block deployment of images with critical vulnerabilities using a Kubernetes admission controller.

What catches people: The Qualys-based scanner is slower than open-source alternatives. A large image (500 MB or more) can take 5 to 10 minutes to scan, which adds latency to your CI/CD pipeline if you scan on push.

GCP Artifact Registry with Container Analysis

Artifact Registry (the successor to Container Registry, which is now deprecated) integrates with Container Analysis for automatic vulnerability scanning. On-push scanning is enabled by default for Artifact Registry repositories, and it scans both OS packages and language packages (Go, Java, Python, Node.js).

Pricing: Container Analysis scanning costs $0.26 per image scanned. Continuous monitoring -- where existing images are re-scanned when new CVEs are published -- is included at no additional cost after the initial scan. This pricing model is more predictable than ECR Enhanced scanning for teams with large image catalogs.

What I like: The Binary Authorization integration is the strongest admission control story among the three clouds. You can require that images are both scanned and signed before they can be deployed to GKE. The Grafeas-based attestation model is flexible and supports custom attestors.

Open-Source Scanners: Trivy, Grype, and When to Use Them

You do not have to rely solely on cloud-native scanners. Open-source tools often provide better coverage, faster scanning, and more flexibility.

Trivy

Trivy (by Aqua Security) is the most popular open-source container scanner. It scans OS packages, programming language dependencies, IaC files (Terraform, CloudFormation), and Kubernetes manifests. A typical image scan takes 5 to 15 seconds, which is fast enough to run in CI without slowing down builds.

Why teams use it: Trivy has the best vulnerability database coverage of any open-source scanner. It pulls from NVD, Alpine SecDB, Red Hat OVAL, Debian Security Tracker, Ubuntu CVE Tracker, and several language-specific advisory databases. It also supports SBOM generation in SPDX and CycloneDX formats.

Pipeline integration: Run trivy image --severity CRITICAL,HIGH --exit-code 1 your-image:tag in your CI pipeline. The --exit-code 1 flag causes the build to fail if any CRITICAL or HIGH vulnerabilities are found. This is the simplest way to gate deployments on security.

Grype

Grype (by Anchore) is another excellent open-source scanner with a slightly different approach. It scans SBOMs rather than images directly, which means you can generate an SBOM once with Syft (Anchore's SBOM tool) and scan it repeatedly as new vulnerabilities are discovered without re-analyzing the image.

Why teams use it: The SBOM-first approach integrates well with supply chain security workflows. You generate the SBOM at build time, store it alongside the image, and scan it continuously. When a new CVE drops, you scan all stored SBOMs in seconds rather than pulling and re-scanning every image.

Image Signing: Cosign and Notation

Scanning tells you whether an image has known vulnerabilities. Signing tells you whether an image was built by your pipeline and has not been tampered with. Both are necessary for a complete security posture.

Cosign (Sigstore)

Cosign, part of the Sigstore project, is the emerging standard for container image signing. It stores signatures in the same OCI registry as the image, so you do not need a separate signature store. Keyless signing with Fulcio (Sigstore's certificate authority) eliminates the need to manage signing keys -- the CI/CD system's OIDC identity becomes the signing identity.

How it works in practice: Your CI pipeline builds an image, scans it with Trivy, and if the scan passes, signs it with Cosign using keyless signing. The signature is stored in the registry alongside the image. At deploy time, a Kubernetes admission controller (like Kyverno or the Sigstore policy controller) verifies the signature before allowing the pod to start.

Integration with GKE: Binary Authorization on GKE natively supports Cosign signatures as attestations. You create a Binary Authorization policy that requires a Cosign attestation from your CI pipeline, and GKE will reject any image that was not signed by your pipeline.

Notation (Microsoft)

Notation is the OCI-standard signing tool, backed primarily by Microsoft and the Notary Project (CNCF). It stores signatures using the OCI Reference Types specification and integrates tightly with Azure Container Registry. If you are running primarily on Azure and AKS, Notation with Azure Key Vault for key management is the natural choice.

Cosign vs Notation: Both are viable. Cosign has broader adoption and better keyless signing support. Notation has stronger OCI compliance and better Azure integration. If you are multi-cloud, Cosign is the safer choice because it works everywhere. If you are Azure-first, Notation is well-supported and deeply integrated.

Supply Chain Security and SBOMs

The 2021 Executive Order on Improving the Nation's Cybersecurity and subsequent NIST guidance made SBOMs a compliance requirement for software sold to the US federal government. Even if you do not sell to the government, SBOMs are becoming a standard expectation in enterprise procurement and a practical necessity for vulnerability response.

Generating SBOMs

Generate SBOMs at build time, not after the fact. Tools that scan running containers or images to produce SBOMs are less accurate than tools that analyze the build process itself.

• Syft (Anchore) generates SBOMs from container images, file systems, and archives. It supports SPDX and CycloneDX formats and detects packages across 15+ ecosystems.
• Trivy also generates SBOMs as part of its scanning process. Run trivy image --format spdx-json your-image:tag to get an SPDX SBOM.
• Docker Scout generates SBOMs natively for images built with Docker BuildKit.

Store SBOMs alongside your images in the registry (using OCI artifacts) or in a dedicated SBOM repository. When the next critical vulnerability is announced, you can search all your SBOMs to identify affected images in minutes instead of scanning every image in every registry.

The Log4Shell Test

Here is the test that every supply chain security process should pass: if a critical vulnerability is announced in a widely-used library (like Log4j), how long does it take you to answer these questions?

1. Which of our container images include this library?
2. Which of those images are currently running in production?
3. Which services do those images belong to?
4. Who owns those services?

If the answer is "we do not know" or "it would take days to find out," your supply chain security has a fundamental gap. SBOMs, combined with an image inventory that tracks which images are deployed where, should let you answer all four questions within an hour.

Admission Controllers: The Last Line of Defense

Admission controllers are Kubernetes components that intercept requests to the API server before objects are persisted. They are the enforcement mechanism that prevents unsigned, unscanned, or vulnerable images from running in your cluster.

Kyverno

Kyverno is a Kubernetes-native policy engine that uses YAML policies instead of a separate policy language. For container security, Kyverno can verify image signatures (Cosign or Notation), check that images come from approved registries, require specific labels, and block containers running as root.

A basic Kyverno policy that requires Cosign signatures is about 20 lines of YAML. It verifies that every container image in a pod has a valid Cosign signature from your CI pipeline's signing identity. If the signature is missing or invalid, the pod creation is rejected with a clear error message.

OPA Gatekeeper

OPA (Open Policy Agent) Gatekeeper uses the Rego policy language for more complex policy logic. It is more powerful than Kyverno for policies that require cross-resource validation or complex conditional logic, but has a steeper learning curve. If you already use OPA for other policy enforcement, Gatekeeper is the natural choice for admission control.

Cloud-Native Options

• GKE Binary Authorization: The most mature cloud-native admission control. It can require attestations from specific attestors (your CI scanner, your security team) before allowing deployment.
• EKS: No built-in admission control for image verification. Use Kyverno, Gatekeeper, or the Sigstore policy controller as a Kubernetes-level solution.
• AKS: Azure Policy for AKS can enforce basic image policies (allowed registries, no latest tag), but for signature verification, you need Notation and the Ratify admission controller.

Putting It All Together: A Container Security Pipeline

Here is the pipeline that I recommend for production container security, from build to runtime:

1. Build: Use a minimal, patched base image. Pin base image versions with digests, not tags.
2. Scan in CI: Run Trivy with --exit-code 1 for CRITICAL and HIGH vulnerabilities. Fail the build if vulnerabilities are found.
3. Generate SBOM: Use Syft or Trivy to generate an SPDX or CycloneDX SBOM. Store it alongside the image.
4. Sign: Sign the image with Cosign using keyless signing. The signature attests that the image was built by your pipeline and passed scanning.
5. Push: Push the signed image and SBOM to your registry (ECR, ACR, or Artifact Registry).
6. Admit: Kyverno or Binary Authorization verifies the signature at deploy time. Unsigned or untrusted images are rejected.
7. Monitor: Enable continuous scanning in your registry to catch new CVEs in deployed images. Alert on CRITICAL findings and trigger rebuild pipelines for affected images.
8. Runtime: Defender for Containers (Azure), GuardDuty EKS Runtime Monitoring (AWS), or Falco (open source) monitors running containers for anomalous behavior.

This is not a theoretical pipeline -- it is what production-grade container security looks like in 2026. Each step adds a layer of protection, and the combination provides defense in depth from build time through runtime.

Cost Reality Check

Container security tooling costs add up. Here is what a team pushing 200 images per day to a 50-node cluster should budget:

• Open-source scanning (Trivy/Grype): Free. Compute costs for running scans in CI are negligible.
• ECR Enhanced Scanning: About $540 per month (6,000 scans at $0.09).
• Defender for Containers on AKS: About $350 per month (50 vCPUs at $7).
• GCP Container Analysis: About $1,560 per month (6,000 scans at $0.26). However, continuous monitoring is free after initial scan.
• Cosign signing: Free. Key storage in KMS/Key Vault costs a few dollars per month.

The most cost-effective approach is to use open-source scanners (Trivy) in CI and cloud-native scanning in the registry for continuous monitoring. This gives you fast CI feedback and ongoing protection without paying per-scan costs twice.