Container Image Security Scanning in CI/CD Pipelines

Roughly 87% of container images in production carry a high-severity or critical vulnerability. That's not a niche problem: container adoption sits north of 70% of organizations at this point, so this is the default state of most fleets, not an edge case. The only way to catch up is to move the scan earlier, into the CI/CD pipeline itself, before an image ever reaches a registry. This piece walks through how that actually works: where scanning fits in the lifecycle, which tools do the job, and how to roll it out without grinding deploys to a halt.

The attack surface isn't just the image anymore. The pipeline that builds it, the registry that stores it, and the code feeding both are now just as exposed. And automatically generated container build files, manifests, and dependency bumps are multiplying image variants faster than any manual review process can keep up with. Nobody's eyeballing every generated container build file line by line. That alone makes automated, pipeline-native scanning less of a nice-to-have and more of a baseline requirement.

The cost of finding a vulnerability in production versus in the pipeline

Secrets are the clearest example of how this plays out. In the last two years, 57% of organizations reported a security incident tied to exposed secrets in insecure DevOps workflows, things like an API key committed to a repo or baked into an image layer. Catching that in a pre-commit hook or a pipeline scan costs a few seconds of build time. Catching it after the image is running in production costs an incident response cycle, a credential rotation, and possibly a disclosure conversation with customers.

Zooming out, the dollar figures get serious. Software supply chain attacks are on pace to cost the global economy $80.6 billion in 2026, a 76% jump from 2023. That's not scanning tool marketing; it's the trend line for what happens when vulnerable components move downstream unnoticed.

Finding a critical vulnerability in production is expensive across multiple fronts at once: engineering time pulled off roadmap work, incident response overhead, and customer trust that doesn't come back easily. Finding the same vulnerability in the pipeline costs almost nothing. It's a failed build step. Nobody gets paged.

And the exposure is not theoretical. Around 12% of cloud environments currently have publicly exposed containers running high-severity vulnerabilities with known, working exploits, a meaningful slice of the internet sitting there, waiting. That's a meaningful slice of the internet sitting there, waiting.

Scanning across the container lifecycle: build, registry, and runtime

Container threat modeling generally breaks into five phases: build, registry, deployment, runtime, and response. Each phase carries its own flavor of risk, and treating them as one blob is how gaps happen.

At build time, the risks are things like unpatched dependencies pulled in during npm install or pip install, Dockerfiles that run as root by default, hardcoded credentials left in an early layer, and base images that were vulnerable the day they were published.

At the registry stage, the risk shifts to trust. Is the image signed? Is the SBOM attached to it actually current, or is it three versions stale? Pulling an unverified image from a public registry, thinking it's a safe base to build from, is its own distinct attack vector, and it's one teams underestimate constantly.

At runtime, the risks change shape again: privilege escalation inside a container, container escape into the host, processes spawning that shouldn't exist, lateral movement across the cluster once an attacker has a foothold. Scanning alone won't catch all of that. Runtime protection is a separate discipline. But a huge share of runtime incidents trace back to something that could've been caught earlier, in the build or registry stage, if the scan had been positioned correctly.

Structuring the pipeline: stages, gates, and what to block versus warn

A typical pipeline sequence looks something like: code push, then SAST, then SCA, then build, then container scan, then IaC scan, then deploy to staging, then DAST, then a policy gate, then deploy to production.

The container scan step, sitting right after build and right before the image gets pushed to a registry, is the shift-left moment this whole approach is built around. Scan the image the moment it exists, before it's registered anywhere, and a vulnerable image never gets the chance to propagate to a dozen other services pulling from that same registry.

Gating logic matters as much as gate placement. A workable default: block the build outright on any critical vulnerability. Warn, but don't block, on high-severity findings, unless the volume crosses some threshold the team has agreed on ahead of time. GCP's Cloud Build documentation shows a concrete version of this: blocking on CRITICAL or HIGH severity as a single combined gate. Simple, defensible, easy to explain to a team that's new to this.

Informational findings shouldn't block anything, ever. And enforcement should ramp up over time rather than land all at once. This approach, warn first, then tighten, is really a lesson in change management as much as security. Turning on hard blocking against a decade of accumulated CVEs on day one causes a team to find a way to route around the pipeline. Adoption dies fast when a new control feels like it appeared out of nowhere and stopped every deploy in its tracks.

Scanning tools that fit a pipeline-first workflow: open-source options

Trivy, built by Aqua Security and MIT licensed, is probably the most widely deployed scanner in the cloud-native world right now. It covers container images, infrastructure-as-code files, and dependency manifests in one tool, and it's genuinely fast, which matters a lot when it's sitting in a build step someone is waiting on.

Grype, from Anchore, takes an SBOM-aware approach. It can scan container images directly, filesystems, or SBOMs that were generated separately, and it checks across OS packages, libraries, and language-specific dependencies. Its JSON output slots easily into CI/CD tooling and compliance reporting, which makes it a good fit for teams that need an audit trail alongside the scan itself.

Clair suits teams that want a scanning service they run and control themselves. It takes more setup than the other two tools out of the box, but it keeps its vulnerability database current and exposes an API, so it works as an internal, always-on container security service rather than a one-off command-line check.

Docker Scout's Docker Personal plan includes one free Scout-enabled repository plus unlimited public Hub repositories. For a small team or an open-source project just getting a scanning habit started, that's a zero-dollar entry point.

When commercial and platform-integrated scanning tools earn their cost

The real buying question in 2026 isn't which scanner surfaces the most CVEs against a base image. Any of them will produce a long list. Teams need a tool that helps them figure out what matters, enforces policy inside CI/CD without extra glue code, and gets fixes shipped without burying developers under noise from base-image alerts they can't act on anyway.

Snyk leans developer-first. It fits directly into CI/CD pipelines and runs automated checks across code dependencies and container images in the same workflow, which cuts down on context switching for the engineer who has to actually fix something.

Aqua Security checks images against the NVD plus its own research feed, and its Kubernetes integration goes further than most, with admission controls that can stop a pod from running at all if it violates policy. That's enforcement happening at the cluster boundary, not just in a CI report nobody reads.

Wiz takes an agentless approach, mapping container visibility onto a broader cloud security graph. It correlates image vulnerabilities with actual runtime exposure, exposed secrets, and cloud IAM permissions all at once. That graph model is the real differentiator: a CVE that sits behind three layers of network isolation and no public IAM path is a very different risk from the same CVE sitting on an internet-facing service account.

The CVE noise problem and how to prioritize what needs fixing

A vulnerability scanner that's actually useful ranks findings by real exposure, not by raw CVE count or a severity score pulled straight from NVD. That distinction sounds small. It isn't, even though that distinction sounds small.

Reachability is the filter that makes the difference. Context about how a container is actually deployed, what network paths it exposes, and which workloads it talks to changes which CVEs deserve attention. A critical vulnerability in a package that's imported but never called in a hot code path just isn't the same risk as the same CVE sitting in something that handles every incoming request.

Base-image noise is where this gets painful in practice. One upstream base image update can dump hundreds of new CVEs onto a team's plate overnight, and the overwhelming majority of them are unexploitable in that specific workload's context. Nobody wins by triaging all of them by hand.

A workable prioritization order looks like this: exploitability first, then severity, then reachability, then whether a fix is even available yet. Teams that gate purely on CRITICAL or HIGH severity, with no reachability context layered in, end up blocking deploys over findings nobody could ever exploit. That's how developer trust in the security gate erodes, and once it erodes, people start finding ways around it.

SBOMs and supply chain integrity: the compliance layer that scanning alone cannot provide

Scanning tells a team about known CVEs in things it can identify. It says nothing about what's actually inside an image if that component was never properly declared. That's the gap an SBOM, a software bill of materials, is built to close, and it's a meaningfully different problem than CVE detection. Given that supply chain attacks are projected to cost $80.6 billion globally in 2026, a 76% rise from 2023, knowing what's in an image is no longer optional homework.

The regulatory ground has shifted recently too. CISA, the NSA, the FBI, and international partners released updated 2026 Minimum Elements for a Software Bill of Materials, replacing the older NTIA 2021 baseline. That's the current floor for what counts as a legitimate SBOM.

In the EU, the Cyber Resilience Act has been in force since December 2024. It requires a machine-readable SBOM for any product with digital elements sold in the EU, covering at least top-level dependencies, and its various obligations are phasing in through 2026 and 2027. The September 2026 reporting requirements are active right now, not some future deadline to plan around later.

On the US federal side, OMB Memorandum M-26-05 rescinded the mandatory software attestation requirement, moving agencies toward a decentralized, risk-based approach where SBOM use is now at each agency's own discretion. Meanwhile the FDA has required SBOMs for certain medical device submissions since March 2023. So the regulatory picture isn't one uniform standard, it depends heavily on which market and which sector a team is selling into.

Image signing and admission control: enforcing trust at the cluster boundary

Sigstore and Cosign, the SLSA framework, and Kubernetes admission controllers form a three-part setup that teams are increasingly adopting to stop supply chain attacks at the cluster edge.

Cosign signs images using ephemeral keys tied to OIDC identity, so there's no long-lived private key sitting around waiting to leak. Docker Content Trust takes a different route, using Notary v1 for verification. Different trust models, same underlying goal: prove an image is what it claims to be and hasn't been swapped out somewhere along the way.

Admission controllers, with Kyverno and OPA Gatekeeper being two widely used options, sit as the last checkpoint before deploy. They reject any pod whose image doesn't carry a valid signature, or whose image digest hasn't cleared the scan policy the pipeline was supposed to enforce. It's not enough for a pipeline to declare a rule if nothing at the cluster boundary checks that the rule was followed.

OPA, using the Rego policy language, can write rules that apply across Terraform, Kubernetes manifests, and CI/CD systems all at once, with Conftest validating configs against those same policies before anything ships. Another tool takes a lighter path: a Kubernetes-native engine with plain configuration-file rules, no separate policy language to learn. Trade-off between flexibility and simplicity, and which one fits depends on how much policy complexity a team actually needs.

Rolling out pipeline scanning without stalling deployment velocity

None of this works if it tanks shipping speed, and that's the real risk teams worry about going in. The fix is non-blocking scans early, progressive enforcement over time, and folding all of it into workflows developers are already using instead of bolting on a separate portal nobody checks.

The upside for getting this right is well established: organizations with proper CI/CD integration see 25% faster lead times and 50% fewer failures compared to organizations without it. That's the baseline a security rollout has to protect, not undercut. Security scanning that erases those gains has failed at its actual job.

A staged rollout keeps that baseline intact. The first phase runs every scan, blocks nothing, and establishes what the current baseline of findings looks like. Phase two: start blocking on critical vulnerabilities only. Phase three: tighten the high-severity threshold gradually as teams work through their existing backlog. Phase four: layer in mandatory SBOM generation and image signing as standard, non-negotiable steps.

Run scans inline, inside the pipeline itself, rather than shipping images out to an external service for analysis. Keeping the scan local matters for speed, and for teams handling anything sensitive, it matters for keeping proprietary image contents inside the perimeter.