Implementation Guide
Container Scanning Best Practices
A practical guide to implementing container scanning across your development lifecycle. From shift-left integration to runtime monitoring, these practices are drawn from how mature DevSecOps organizations secure their container workloads.
1
Shift Left: Scan Early and Often
The cost of fixing a vulnerability increases dramatically as it moves through the pipeline. A CVE caught in a developer's pull request takes minutes to fix: update a dependency, push a new commit, and the CI re-runs. The same CVE caught in production requires incident response coordination, emergency patch cycles, and potentially customer notifications.
Shift-left means integrating scanning as early as possible. The ideal first integration point is the CI/CD pipeline. Every image build triggers a scan. If the scan detects vulnerabilities that violate your policy (e.g., any critical CVE, or any high CVE with a known exploit), the build fails and the developer is notified with the specific package, CVE, and suggested fix version.
Some teams go further and scan Dockerfiles before building. Static analysis of the Dockerfile can catch issues like using an unpinned base image tag (
FROM node:latest instead of FROM node:20.11.0-bookworm-slim@sha256:...), running as root, or installing packages without version pinning.Practical Tip
Start with a non-blocking scan that reports results without failing the build. This lets developers see what the scanner finds without disrupting their workflow. Once the team is comfortable with the output and false positive rate, switch to a blocking policy. A common starting policy: fail on critical CVEs with a fix available. This avoids blocking on vulnerabilities that cannot be remediated yet.
2
CI/CD Pipeline Integration
Every major CI/CD platform supports container scanning integration. The pattern is consistent across GitHub Actions, GitLab CI, Jenkins, CircleCI, and others: add a scanning step after the image build step, before the push step.
A well-designed scanning pipeline stage does four things:
Scan the image
Run the scanner against the just-built image. Most scanners accept a local image reference or tarball.
Generate SBOM
Produce a CycloneDX or SPDX SBOM alongside the vulnerability report. Store it as a build artifact.
Evaluate policy
Compare scan results against your organization's policy. Return a pass/fail decision based on severity thresholds, fix availability, and exceptions.
Upload results
Push the scan report and SBOM to a central vulnerability management platform where security teams can aggregate and track findings across all projects.
Cache vulnerability databases locally. Downloading the full NVD on every CI run wastes bandwidth and slows builds. Most scanners support a local database cache that can be updated on a schedule (e.g., hourly) and shared across pipeline runs.
Set scan timeouts. Some images are large and scanning can take minutes. Set a reasonable timeout (typically 5-10 minutes) to prevent scanning from becoming a bottleneck in your CI/CD pipeline.
3
Continuous Registry Scanning
CI/CD scanning catches vulnerabilities at build time. But new CVEs are disclosed constantly. An image that was clean when built may have critical vulnerabilities a week later when a new CVE affecting one of its packages is published.
Continuous registry scanning solves this by periodically re-scanning all images stored in your container registry. Most container registries (AWS ECR, Google Artifact Registry, Azure Container Registry, Harbor) offer native or plugin-based scanning. Third-party platforms like Snyk, Aqua, and Sysdig can also connect to registries for continuous scanning.
Recommended frequency: Daily at minimum. Organizations with strict compliance requirements often scan every 4-6 hours. The scan frequency should be driven by your vulnerability SLA: if your policy requires critical CVEs to be addressed within 24 hours, you need to detect them within that same window.
Tag immutability: Enforce tag immutability in your registry so that a given tag always points to the same image digest. Without this, someone can push a new image to an existing tag, and the registry scan results for that tag become stale. Use digest-based references (e.g.,
image@sha256:abc123) in production deployments.4
Policy Enforcement and Admission Control
Scanning without enforcement is monitoring. Scanning with enforcement is security. The goal is to create gates where unscanned or non-compliant images are prevented from progressing.
CI/CD gates are the first line: fail the pipeline if the image does not meet your vulnerability policy. This prevents the image from being pushed to the registry in the first place.
Kubernetes admission control is the last line. Tools like OPA Gatekeeper, Kyverno, and built-in Kubernetes admission webhooks can reject pod deployments if the image has not been scanned, was scanned more than N hours ago, or has vulnerabilities exceeding a threshold. This catches any image that bypassed CI/CD scanning (e.g., images pulled from external registries, images promoted from dev environments without rescanning).
Example Policy Ladder
BLOCK
Any image with a critical CVE that has a fix available. No exceptions.
BLOCK
Any image running as root without explicit exception approval.
WARN
Images with high-severity CVEs older than 14 days without a remediation plan.
WARN
Images using base images more than 30 days old.
AUDIT
All medium and low severity CVEs logged for trending and reporting.
5
Runtime vs. Build-Time Scanning
Build-time and runtime scanning serve different purposes and complement each other. Neither alone is sufficient.
| Aspect | Build-Time Scanning | Runtime Scanning |
|---|---|---|
| When | During CI/CD, before deployment | After deployment, in production |
| What it catches | Known CVEs, misconfigurations, secrets, license issues | Anomalous behavior, zero-days, privilege escalation, network probes |
| Approach | Static analysis of image layers and manifests | Behavioral monitoring via eBPF, syscall tracing, or sidecar agents |
| Strength | Preventive. Stops bad images from shipping. | Detective. Catches what static analysis misses. |
| Limitation | Cannot detect zero-day exploits or runtime-only threats | Reactive. The threat is already running when detected. |
Most organizations start with build-time scanning because it provides the highest return on investment. Runtime scanning is added as the security program matures and as containerized workloads increase.
6
Remediation Workflows
Scanning without remediation is just generating reports. The value of scanning is only realized when vulnerabilities are actually fixed. Effective remediation workflows connect scan results to developer action.
Automated fix PRs. Some scanners (notably Snyk and Mend) can automatically generate pull requests that update the vulnerable dependency to a fixed version. This reduces the remediation burden on developers to reviewing and merging a PR rather than researching the fix themselves.
Base image updates. A large percentage of container vulnerabilities come from the base image OS layer. Establishing a regular base image rebuild cadence (weekly is common) ensures that OS-level patches are incorporated promptly. Pin your base images to a specific digest, but update that digest on a schedule.
Vulnerability SLAs. Define remediation timelines based on severity. A common framework:
Critical
24-48 hours
High
7 days
Medium
30 days
Low
90 days
Exception management. Not every vulnerability can be fixed immediately. Some have no patch yet. Others exist in code paths that are not reachable in your application. Establish an exception process where a security engineer can accept the risk for a defined period with documentation. Scan tooling should support suppression rules that honor these exceptions without losing visibility.
7
Compliance Alignment
Container scanning maps directly to controls in major compliance frameworks. Demonstrating automated, continuous vulnerability scanning is increasingly expected in audit evidence packages.
NIST SP 800-190 (Application Container Security Guide) specifically addresses container image vulnerabilities and recommends countermeasures including image scanning, trusted registries, and runtime monitoring. It is the most directly relevant NIST publication for container security.
CIS Docker Benchmark includes controls for image vulnerability scanning (4.1), using trusted base images (4.2), not using root (4.1), and removing unnecessary setuid binaries (4.6). Many scanning tools can evaluate CIS Benchmark compliance directly.
CIS Kubernetes Benchmark addresses image scanning from the cluster perspective: admission control for unscanned images, namespace-level scanning policies, and pod security standards that limit what images can do at runtime.
Audit Evidence Checklist
Scan results for all production container images (timestamped, with scanner version)
SBOM documents for each image in SPDX or CycloneDX format
Vulnerability remediation records showing time-to-fix metrics
Policy definitions (what severity levels block deployment)
Exception records with risk acceptance justification and expiry dates
Continuous monitoring evidence (registry scan schedules and results)
Admission control configuration (Gatekeeper/Kyverno policies)
8
Base Image Strategy
The choice of base image has an outsized impact on your vulnerability posture. A full Ubuntu or Debian image ships hundreds of packages, many of which your application does not need. Each unnecessary package is an additional attack surface.
Prefer minimal base images. Alpine Linux, distroless images (from Google), and scratch-based images dramatically reduce the number of packages in the image. A distroless Node.js image may have 50 packages compared to 400+ in a full Debian-based Node.js image. Fewer packages means fewer potential vulnerabilities.
Pin base images by digest, not tag. Tags like
node:20 can point to different images over time. Pinning by digest (node:20@sha256:abc...) ensures reproducible builds and makes it explicit when the base image changes.Establish an internal golden image catalog. Maintain a set of approved, pre-scanned base images that teams must use. Rebuild these on a regular schedule (weekly) so teams always have a fresh, patched starting point. This centralizes base image maintenance and reduces the scanning burden across the organization.
Ready to Choose Your Scanner?
See how open-source and commercial container scanning tools compare across features, integration, and enterprise capabilities.