Container Image Security Scanning: A Practitioner's Guide
Container image scanning has become a standard DevSecOps practice, but the raw output of most scanners — hundreds of CVEs across multiple severity levels — provides little actionable guidance without a framework for interpreting and prioritizing results. Teams that implement scanning without a prioritization strategy end up ignoring scanner output because the noise-to-signal ratio is unmanageable.
This guide covers the tools that work in practice, base image selection as a proactive vulnerability reduction strategy, how to integrate scanning into CI/CD pipelines without blocking every build, and how to identify the subset of scanner findings that represent real exploitability risk.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts — distilled for practitioners. 50,000+ subscribers. No noise.
Scanner Selection: Trivy, Grype, and Snyk Compared
The three most widely deployed open-source and commercial container scanners each have different strengths that make them appropriate for different contexts.
Trivy (Aqua Security, open source): The most versatile scanner in the ecosystem — scans container images, filesystems, Git repositories, IaC configurations (Terraform, CloudFormation, Kubernetes manifests), and SBOMs in a single tool. Trivy is the scanner used by GitHub's Dependency Review Action and is integrated into many CI/CD platforms natively. Its vulnerability database pulls from multiple sources (NVD, GitHub Security Advisories, OS-specific advisories) and updates frequently. For teams that want a single scanner across their entire stack (containers, IaC, code), Trivy is the practical default.
Grype (Anchore, open source): Pairs with Syft for SBOM-first scanning workflows — Syft generates the SBOM, Grype scans it. This separation is valuable when you want to generate an SBOM as an artifact and scan it separately or at a later stage. Grype has a smaller feature set than Trivy but excels in its core container and SBOM scanning use case.
Snyk Container (commercial with free tier): Provides the most actionable output of any scanner, including base image upgrade recommendations that show exactly how many vulnerabilities would be eliminated by switching to a specific newer base image version. Snyk's fix advice is its primary advantage over open-source alternatives. The developer-facing interface (IDE plugins, pull request status checks) is also more polished than Trivy or Grype.
Base Image Hardening: The Highest-Leverage Control
The single most effective container security control is base image selection. Most container vulnerability density comes from OS packages in the base image — not from your application code. Choosing a minimal base image eliminates entire categories of vulnerabilities that never needed to be present.
Base image hierarchy from most to least vulnerable: full Ubuntu/Debian (hundreds of CVEs in the OS package set, many irrelevant to your application), Ubuntu/Debian slim variants (smaller package set, reduced but still significant vulnerability exposure), Alpine Linux (musl libc-based, minimal package set, dramatically lower CVE count but may require compatibility testing), Chainguard/Wolfi-based images (built for minimal vulnerability footprint, often zero-CVE at time of publication), Distroless images (Google's base images with no package manager, shell, or OS utilities — only the application runtime and its direct dependencies).
Distroless images (gcr.io/distroless/*) are the strongest choice for production deployments where you do not need a shell or package manager in the running container. They eliminate the attack surface from every OS utility that is not required to run your application. The tradeoff is that debugging requires separate tooling (ephemeral debug containers in Kubernetes) — but in production, this is an acceptable operational change for the security benefit.
CI/CD Pipeline Integration Without Breaking Builds
Integrating container scanning into CI/CD pipelines requires a policy that distinguishes between scan results that should block a build and results that should generate alerts without blocking. Blocking every build with any HIGH or CRITICAL finding will grind deployment to a halt — most images have HIGH findings in packages that are not reachable by your application.
Practical pipeline policy: Block builds on CRITICAL findings with a known exploit in a reachable package (scanner support for reachability analysis varies — Snyk and Trivy with --ignore-unfixed flag provide this). Alert (do not block) on HIGH findings and require resolution within a defined SLA (typically 30 days). Ignore Medium and Low unless the finding is in a package your application directly calls.
Tooling for CI/CD integration: Trivy with `--exit-code 1 --severity CRITICAL --ignore-unfixed` blocks only on CRITICAL CVEs with available fixes. Pair this with a `.trivyignore` file for documented exceptions with expiration dates. For Kubernetes admission control, integrate scanning into the cluster via admission webhooks (Trivy Operator, Snyk's Kubernetes integration) that prevent deployment of images with unacceptable findings.
Dockerfile Security Best Practices
Container security starts in the Dockerfile. Misconfigured build instructions create vulnerabilities that no scanner will surface because they represent misconfigurations rather than CVEs.
Dockerfile security checklist: (1) Never run as root — add a `USER` instruction to run the container process as a non-root user with the minimum permissions required. (2) Use specific image tags, not `latest` — `FROM python:3.12.4-slim` not `FROM python:latest`. Floating tags allow the base image to change unpredictably between builds. (3) Minimize layers that run as root — separate `apt-get install` operations from application code and drop privileges before copying application files. (4) Do not include secrets in build arguments or environment variables — use runtime secret injection via Kubernetes Secrets or cloud secret managers. (5) Use multi-stage builds to separate build dependencies from runtime dependencies — your final image should contain only what the running application needs.
Linting Dockerfiles: Hadolint is the standard Dockerfile linter and enforces many of these best practices automatically. Integrate it into your pull request checks to catch Dockerfile issues at authoring time rather than at scan time.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, remediation steps, and every daily briefing.
The bottom line
Container security scanning is only valuable if the output is acted on. The combination of distroless or Alpine base images (eliminates most of the CVE noise), pipeline policies that block only on CRITICAL exploitable findings, and periodic registry scanning for post-build CVE disclosure covers the vast majority of container image risk. Scanner output without a prioritization and remediation workflow is just noise.
Frequently asked questions
What is a distroless container image?
Distroless container images (introduced by Google, now widely available from Chainguard and others) contain only the application runtime and its direct dependencies — no shell, no package manager, no OS utilities. This dramatically reduces the attack surface and CVE count compared to traditional base images. The main operational tradeoff is that debugging requires ephemeral debug containers rather than exec-ing into a running container — but this is manageable in Kubernetes environments.
How often should I scan container images?
Scan at three stages: at build time (catches vulnerabilities present when the image is created), at push to registry (final gate before deployment), and continuously in the registry (catches CVEs published after image creation). Most organizations scan at build and push but miss the registry continuous scan — which means deployed images can become vulnerable days or weeks after deployment as new CVEs are published for packages in the image.
What is the difference between image scanning and runtime container security?
Image scanning analyzes the container image for known CVEs in packages and libraries before or during deployment. Runtime container security monitors the behavior of running containers and detects anomalous activity — unexpected processes, outbound connections to suspicious IPs, privilege escalation attempts, filesystem writes to unexpected locations. Image scanning is a shift-left control; runtime security is a detection and response control. Both are needed — Falco (open source) and Aqua, Sysdig, and Prisma Cloud (commercial) provide runtime security.
How do I handle containers that cannot be updated immediately?
When a vulnerable container cannot be patched immediately (dependency compatibility issues, vendor support timelines), document the exception with a risk acceptance, a compensating control, and an expiration date. Compensating controls for vulnerable containers: network policy restrictions (limit the container's inbound and outbound connectivity to the minimum required), admission control policies that prevent the vulnerable image version from being deployed in production, and enhanced runtime monitoring. Use a `.trivyignore` file with expiration dates to prevent scanner exceptions from becoming permanent.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.