Container Security Scanning: From Detection to Deployment

What is container security scanning?

Container security scanning is an automated process that analyzes container images and running containers to identify vulnerabilities, misconfigurations, and security threats before deployment.

Containerized environments introduce risks traditional scanners weren't built for. A single image bundles application code, third-party libraries, and OS components into one artifact, so a vulnerability in any layer becomes a vulnerability in the final image. Containers are also short-lived by design, spinning up and down constantly, so a scan that only runs once at build time can miss threats that emerge after deployment. Registries and orchestration platforms like Kubernetes add their own configuration surface too, giving attackers more paths to exploit if scanning doesn't extend beyond the image itself.

These dynamics are why 2025's cloud intrusions most often relied on long-standing weaknesses, vulnerabilities, exposed secrets, and misconfigurations, rather than new attack techniques. Scanning that covers the full lifecycle, not just the image, directly addresses the entry points attackers rely on most.

wiz academy

What is Container Security? [Securing Containers 101]

Read more

What does container scanning detect?

Container scanning examines several distinct categories of risk, each introduced at a different point in the container lifecycle. Understanding what scanning covers helps you evaluate whether your current tooling addresses your real exposure. Here’s a snapshot of different detections.

Knowing what scanning detects sets up the next question: how do scanners actually do this work across the container lifecycle?

Container Security Best Practices [Cheat Sheet]

Level up your container defense. Get the 9-page blueprint for securing your environment. We’ve included specific code examples, visual diagrams, and the best open-source tools to help you harden your containers with confidence.

Your work email here

Download

How container scanning works

Container scanning operates through several distinct layers, each targeting a different point in the container's life. Together, these layers form a defense that spans from the first line of a Dockerfile to a container running in production.

Static image scanning

Static image scanning analyzes a container image's layers before deployment, decomposing the image into its constituent parts (base OS, application code, and dependencies) and checking each against known vulnerability databases. Because this analysis happens before the image runs, it catches issues like outdated packages or embedded secrets at the earliest possible point.

Registry scanning

Registry scanning checks images at rest in your container registry and enforces pull policies that prevent vulnerable or non-compliant images from being pulled into production. This acts as a checkpoint between build and deployment, catching images that may have passed earlier scans but are now flagged due to newly disclosed vulnerabilities.

CI/CD pipeline scanning

Integrating scanning directly into your CI/CD pipeline embeds security checks into the build process itself. A fail-fast policy stops a build when a critical vulnerability is detected, preventing risky images from progressing further down the pipeline. This allows your team to eliminate issues quickly and early in the security flow.

Runtime scanning

Runtime scanning monitors containers while they're running, watching system calls, processes, and network behavior for compromises that static, pre-deployment scans can't catch. A container that passes every check can still be compromised after deployment, through a zero-day, a misused credential, or an attacker pivoting from another resource, and pairing that runtime visibility with your broader cloud context turns an isolated alert into a prioritized, actionable finding.

Real-world example: Wiz Research found CVE-2024-0132, a container-escape vulnerability in the NVIDIA Container Toolkit. This vulnerability allowed a malicious container image to access the host’s root file system. Continuous vulnerability management practices like runtime scanning helped Wiz prevent these issues by consistently reviewing and analyzing containers.

SBOM generation and dependency mapping

Generating a software bill of materials (SBOM) creates a complete inventory of every component, library, and dependency inside a container image. This inventory becomes critical the moment a new vulnerability is disclosed. When Log4Shell was disclosed, teams with an existing SBOM could immediately query which images contained the affected library and prioritize remediation. Teams without one had to rebuild that context from scratch, often taking days to determine their actual exposure. 

Each of these layers plays a role at a different stage of development, which raises the question of how they map onto your actual workflow from the first commit to a running production container.

wiz academy

Guide to SBOM Tools: 5 Picks for Enterprise Security Teams

Compare the 5 best SBOM tools for enterprise security teams. Learn key features, SBOM formats, and how to build SBOM generation into your security workflow.

Read more

Container scanning across the development lifecycle

Container scanning distributes checks across build, registry, deployment, and runtime stages, each catching different categories of risk at the point where they're cheapest to address.

Build phase: Dockerfile scanning and base image selection

During the build phase, scanning examines your Dockerfile and the base image you've chosen as your starting point. Without this check, a vulnerable base image pulled from a public registry becomes the foundation for every image built on top of it, embedding risk before a single line of application code is written. Choosing a minimal, well-maintained base image and scanning the container image early in the build process prevents this inherited risk from compounding downstream.

Registry phase: policy enforcement before images reach production

Once an image is built, it lands in a registry, where policy enforcement determines whether it's allowed to move forward. Without enforcement here, an image with a known critical vulnerability can sit in the registry and still be pulled into a production deployment by any team with access. Enforcing policies at this stage acts as a gate that catches images missed earlier or flagged by newly published CVEs.

Deploy phase: admission controls and pre-deploy checks in Kubernetes

At deployment, admission controllers in Kubernetes evaluate whether an incoming image meets your security requirements before it's allowed to run. Without admission controls, a non-compliant image, perhaps one missing required labels or running with excessive privileges, can be deployed directly into a live cluster with no final check.

Runtime phase: continuous behavioral monitoring of running containers

Once a container is running, continuous behavioral monitoring watches for activity that deviates from expected patterns, such as unexpected network connections or unauthorized file changes. A vulnerability that wasn't known at build time, or a credential that gets compromised after deployment, only becomes visible at this stage. 

This is where agentless runtime scanning delivers the most value. We built Wiz to scan running containers without deploying agents to every workload, giving you continuous runtime visibility while avoiding the operational overhead and performance impact that agent-based approaches introduce.

With scanning distributed across each of these phases, the benefits become clearer once you see how they compound across the lifecycle.

The benefits of container security scanning

Container scanning across the lifecycle delivers benefits that compound as you move from build to runtime.

1. Early vulnerability detection

Catching vulnerabilities during the build phase prevents them from reaching production in the first place. This shift-left approach surfaces issues when they're easiest to fix, before code has been merged, deployed, and built upon by other teams.

2. Reduced Kubernetes attack surface

Scanning Kubernetes manifests for misconfigurations like overly permissive role-based access control (RBAC), exposed dashboards, and containers running with unnecessary privileges reduces the paths available for lateral movement. A misconfigured manifest that grants a workload cluster-admin permissions, for example, can turn a single compromised container into a foothold across your entire cluster. Catching these issues before deployment closes off that path before it exists.

3. Compliance with security standards

Automated compliance scanning checks container configurations against frameworks like the CIS Benchmarks, PCI DSS, SOC 2, and NIST, surfacing gaps before they affect an audit. We built Wiz to scan against more than 100 frameworks, including HIPAA and GDPR, so your security team can identify and remediate compliance gaps continuously rather than scrambling before an audit deadline.

4. Faster CI/CD pipelines

Embedding scanning into CI/CD might seem like it would slow builds down, but the opposite tends to be true over time. Catching issues automatically and early means fewer late-stage rollbacks, fewer emergency patches, and less manual back-and-forth between security and development teams, all of which slow pipelines down far more than an automated scan does.

These benefits depend on scanning actually working as intended, which brings up a set of challenges that teams need to plan for.

Container scanning challenges

Container scanning delivers real value, but implementing it well comes with friction points worth planning for ahead of time. Here are common challenges to scanning.

Alert fatigue from high-volume CVE output

A single scan can return hundreds of CVEs, many of which pose little real risk to your environment. Without a way to filter and prioritize this volume, security teams can quickly become desensitized to alerts, increasing the chance that a genuinely critical finding gets lost in the noise.

Inherited risk from base images

Every vulnerability present in a base image becomes a vulnerability in every image built from it, often without the downstream team realizing it. This inherited risk can persist across dozens of images if the base image itself isn't regularly updated and rescanned.

Ephemeral containers that evade point-in-time scanning

Containers in modern environments are often short-lived, spinning up to handle a task and terminating shortly after. A scan that only runs at a single point in time can miss a container's entire lifecycle, leaving a gap in visibility for workloads that exist for minutes rather than days.

Prioritization without runtime context

A CVSS score alone tells you how severe a vulnerability could be in theory, but not whether it's actually exploitable in your environment. A critical vulnerability in a container with no network exposure poses far less risk than a medium-severity one in a container with a direct path to sensitive data, and CVSS scores alone can't make that distinction.

Scanner supply chain integrity

The scanning tools themselves rely on vulnerability databases and signature feeds that need to stay current and trustworthy. A scanner relying on an outdated database can miss newly disclosed vulnerabilities, while a compromised feed could theoretically introduce false negatives at scale.

These challenges point toward a set of practices that help teams get more consistent value from container scanning.

Container scanning best practices

The following practices help teams turn container scanning from a point-in-time check into consistent, lifecycle-wide protection.

1. Use minimal base images to reduce inherited CVE surface

Choosing a distroless or Alpine-based image instead of a full operating system image dramatically reduces the number of packages, and therefore the number of potential vulnerabilities, present from the start. Starting from a bloated base image means inheriting CVEs in packages your application never even uses.

2. Integrate scanning into CI/CD and fail builds on critical findings

Embedding scanning into your CI/CD pipeline and configuring it to fail builds when critical vulnerabilities are detected stops risky images before they reach a registry. Without this gate, a critical finding might only surface after the image has already been pulled into multiple environments.

The following GitLab CI configuration shows this gate in practice, where the scan stage fails the pipeline if Trivy detects any critical vulnerabilities, preventing the deploy stage from running.

# Sample integration of a security scanner in GitLab CI
stages:
  - build
  - scan
  - deploy

build:
  stage: build
  script:
    - docker build -t my-image .

security_scan:
  stage: scan
  script:
    - trivy image --exit-code 1 --severity CRITICAL my-image

deploy:
  stage: deploy
  script:
    - docker push my-repo/my-image:latest

3. Enforce admission controls to block non-compliant images

Admission controls in Kubernetes act as a final checkpoint, blocking unscanned or policy-violating images from being deployed. Without this enforcement, an image that bypassed earlier checks, whether through human error or a process gap, can still make it into a running cluster.

4. Generate and maintain SBOMs for production images

Maintaining an up-to-date SBOM for every production image gives your team an immediate answer when a new vulnerability is disclosed in a widely used library. Without an SBOM, teams are left manually searching through images to determine exposure, often under time pressure.

5. Prioritize findings by runtime context, not CVSS score alone

Using runtime context to prioritize vulnerabilities, such as whether a container is internet-facing or has access to sensitive data, ensures remediation effort goes toward issues that matter most. Relying on CVSS scores alone can mean spending days remediating a theoretical critical vulnerability, while a more exploitable medium-severity issue goes unaddressed.

The following pseudocode shows this in practice, where a vulnerability's exploitability and access to sensitive data determine its priority, rather than its CVSS severity rating alone.

# Pseudocode for prioritizing vulnerabilities by runtime context
for vulnerability in scan_results:
    if is_exploitable(environment, vulnerability) and has_sensitive_access(environment):
        raise_alert(vulnerability)
    elif is_exploitable(environment, vulnerability):
        schedule_for_remediation(vulnerability)
    else:
        log_for_review(vulnerability)

6. Scan continuously at runtime, not just at build time

Extending scanning into runtime catches threats that emerge after deployment, including newly disclosed vulnerabilities and behavioral anomalies that indicate compromise. A build-time-only approach leaves a container's entire production lifespan unmonitored.

7. Never store secrets in image layers

Storing secrets like API keys or passwords in image layers leaves them recoverable even if a later layer deletes the file, since earlier layers remain part of the image's history. Using a dedicated secrets manager keeps credentials out of the image entirely, removing this risk at the source.

With these practices in mind, choosing the right scanning tool comes down to a specific set of capabilities.

How to choose a container scanning tool

Evaluating container scanning tools comes down to a handful of capabilities that determine how much real protection a tool provides across your environment.

• Lifecycle coverage. The tool should scan across build, registry, CI/CD, and runtime, rather than focusing only on static image analysis.

• Agentless deployment. Agentless scanning removes the overhead of installing and maintaining agents on every workload, accelerating time to value and reducing operational burden.

• Runtime context for prioritization. The tool should connect scan findings to runtime data, such as network exposure and workload behavior, so you can prioritize based on actual risk rather than CVSS score alone.

• CI/CD integration depth. Look for native integrations with your existing pipeline tools, such as GitLab, that support fail-fast policies without requiring custom scripting.

• SBOM generation. The tool should generate and maintain SBOMs automatically, giving you an up-to-date dependency inventory without manual effort.

• Kubernetes and managed service coverage. The tool should scan Kubernetes manifests and extend coverage to managed container services across your cloud providers, not just self-managed clusters.

We built Wiz to deliver agentless coverage across the entire container lifecycle, from Dockerfile to runtime, connecting every finding to the broader context of your cloud environment through the Wiz Security Graph. This means a vulnerability flagged in a container image is automatically tied to its runtime exposure, its network reachability, and its relationship to other resources, giving your team a prioritized view instead of a flat list of CVEs.

Container scanning that stops at the image level leaves your most active attack surface unmonitored. To see the practices covered in this article applied to your own environment, download the Container Security Best Practices Cheat Sheet for a hands-on blueprint you can apply to your build and runtime workflows. Or, book a demo to see how Wiz can unite your cloud security stack.

Automate container security with agentless scanning

Get a hands-on look at how Wiz scans your containers for vulnerabilities, and how WizOS base images can cut your CVE count down to near zero.

Work Email*

First Name*

Last Name*

Country

Phone Number*

Company*

Keep me updated about Wiz product releases, industry news, and events (You can unsubscribe at any time)

Subscribe me to the Wiz blog digest emails

Submit

For information about how Wiz handles your personal data, please see our Privacy Policy.

Your work email here

Get a demo

FAQs about container scanning

Here are answers to some of the most common questions DevSecOps teams have about container scanning.