Container security testing is the program-level practice of validating a containerized workload across five stages: pre-commit, build, registry, admission, and runtime. Each stage maps to specific NIST SP 800-190 controls. This guide covers what each stage tests, the leading 2026 tools per stage, and how to cut false-positive volume so the alerts left on the on-call queue actually deserve attention.
This guide presents a five-stage framework for testing containerized workloads across source, build, registry, admission, and runtime environments.
Container security testing is the practice of validating a containerized workload against named security controls across five surfaces. The scope covers the image, its dependencies, its deployment manifests, and its runtime behavior. NIST SP 800-190 §4.1.1 and §4.4 enumerate the control objectives for image integrity and runtime risk respectively.
The image surface covers package CVEs, Dockerfile misconfigurations, and embedded secrets. IaC covers Helm charts, Kustomize overlays, and Terraform. Runtime covers syscall and process telemetry from the live container. Network covers L3 and L7 flows between pods (Calico, Cilium Hubble). Identity covers ServiceAccount tokens, OIDC federation, and the secrets the workload pulls at startup.
Container security testing is the umbrella program. Container vulnerability scanning is the build-time slice that checks the image's SBOM against CVE feeds. CNAPP posture management adds cloud-account context (IAM, S3, and KMS) and runs continuously. A team that buys a CNAPP and skips pre-commit, admission, or runtime tools still ships a partial program.
Three forces made container security testing a baseline control by 2026: the CVE disclosure rate, the Mean Time to CVE (MTTC) gap between standard and minimal images, and the audit-evidence cadence required by FedRAMP, PCI, and STIG-aligned programs.
Aqua Security's 2024 Annual Cloud Native Security Report counted 28,000 new CVEs disclosed during 2024. A standard public image carries 50–60 of those at ship time, with 15–20 rated high or critical per Minimus platform data. Without build-time scanning, those CVEs enter production untracked.
Mean Time to CVE measures how long, on average, a deployed image waits before its next CVE disclosure hits. Minimus internal benchmarks place MTTC for standard images near 17 days and for hardened minimal images near 64 days, a 3.7× reduction in CVE arrival frequency.
FedRAMP CM-6, PCI-DSS v4.0 §6.3.2, and STIG-aligned packages require a documented testing cadence per artifact. The 3PAO expects scan reports, admission-policy logs, and runtime alerts tied to image digests, not vendor PDFs. That evidence requirement drives the 77.6% of DevSecOps teams reporting weekly-or-faster image scans in the 2024 SANS DevSecOps Survey.
The container security testing pipeline runs as five sequential stages. Each stage owns a class of risk the next cannot see.
Pre-commit testing runs in the developer's environment or as a Git hook. Hadolint lints the Dockerfile for misconfigurations such as running as root, :latest tags, and missing USER directives. Gitleaks and TruffleHog scan the staged diff for embedded secrets. The goal is fail-fast feedback before the build job spins up.
Build-time scanning runs against the freshly built image. Trivy, Grype (paired with Syft for SBOM), Clair, Snyk Container, and Docker Scout all produce CVE reports keyed to image digest. This stage maps to NIST SP 800-190 §4.1.1, which requires an accurate inventory of software components per image.
Signing, attestation, registry policy, and promotion controls can be applied after build and before deployment. The exact enforcement point depends on the CI/CD and registry architecture.
Cosign and Notation sign image manifests; an SBOM diff against the prior digest surfaces newly introduced packages; a base-image policy rejects pushes from an unapproved upstream. Sigstore's Rekor log records every signature.
Admission testing runs inside the cluster as a validating webhook. Kyverno or OPA Gatekeeper rejects pods that fail policy: unsigned images, missing readOnlyRootFilesystem, privileged mode, and hostPath mounts. NIST SP 800-204C and Kyverno's published policy library cover the control language.
Runtime testing observes the live container. Falco, Tetragon, and Tracee read syscalls via eBPF or kernel modules and fire when behavior diverges from policy. NIST SP 800-190 §4.4 covers the threats: in-memory exploits, container escapes (CVE-2024-21626 runC "Leaky Vessels"), and lateral movement via service-account tokens.
Container vulnerability scanning generates an SBOM from a built image, matches every component against CVE feeds, and produces a severity-ranked findings list per image digest. It is the build-time core of container security testing, not the whole program. For background, see open source vulnerability scanners with hardened images.
A scanner reads the image filesystem layer by layer, extracts package metadata (OS packages, language packages, application dependencies), and compares each version against feeds: NIST's NVD, Google's OSV, GitHub Security Advisories, and Linux distribution security trackers. Output is one finding per matched CVE, ranked by CVSSv3 base score.
Scan at three points: every commit (catches new CVEs against the working tree), every push to the registry (catches CVEs that landed between commit and push), and every release. Re-scan production images daily because new CVEs are disclosed against unchanged code.
SBOM-aware scanners (Grype + Syft, Trivy with --sbom) read the published SBOM in CycloneDX or SPDX format and match directly. Filesystem fingerprinting scanners re-walk the image. SBOM-aware is faster and reproducible; fingerprinting catches packages installed outside the package manager. Use both for high-assurance pipelines, per OWASP's Container Vulnerability Scanning guidance.
Four classes of finding dominate the output of a real container security testing pipeline.
Most CVEs in a typical image come from the base. A node:20 or python:3.12 from Docker Hub pulls Debian or Alpine packages the application never touches at runtime. Per Minimus platform data, that overhead averages 50–60 CVEs per image, 15–20 of them high or critical.
Pod specs that omit runAsNonRoot: true, readOnlyRootFilesystem: true, or allowPrivilegeEscalation: false surface at the admission stage. CIS Kubernetes Benchmark v1.8 controls 5.2.x cover these.
Hardcoded API keys, .env files baked into images, and JWT signing keys committed to source are routine findings. Gitleaks and TruffleHog catch most at pre-commit; Trivy --scanners secret catches the rest.
CVE-2024-21626 (runC "Leaky Vessels," CVSS 8.6) and CVE-2021-44228 (Log4Shell, CVSSv3 10.0, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) showed how a vulnerable component plus CAP_SYS_ADMIN or a mounted Docker socket lets a container escape to the host (MITRE ATT&CK for Containers T1611). Testing across all five stages closes the path.
The 2026 tooling field groups cleanly by stage. The table below names the leading tool in each row, its license, and one finding class it catches.
License and detection notes verified against each project's repository as of April 2026.
A CI/CD container security testing pipeline runs the five stages as ordered jobs: build, scan, sign, push, and deploy. Block on new high or critical CVEs in net-new releases; alert (do not block) on existing CVEs in maintenance releases.
A minimal GitHub Actions job builds the image, runs Trivy with --severity HIGH,CRITICAL --exit-code 1, signs the digest with cosign sign, pushes to the registry, and then triggers a Kyverno-gated deploy. Pin action versions (aquasecurity/trivy-action@0.24.0, sigstore/cosign-installer@v3.5.0) so a malicious upstream tag cannot rewrite the workflow.
GitLab CI exposes the same flow via Container-Scanning.gitlab-ci.yml plus Dependency-Scanning.gitlab-ci.yml. The built-in scanner is Trivy-based; the report uploads as gl-container-scanning-report.json for the Security Dashboard. Sign via a Cosign job in the release stage.
Argo Workflows runs the build → scan → sign → push DAG as a WorkflowTemplate, and Argo CD watches a Git-managed policy library for admission. The same Kyverno or OPA policies enforce at admission, so the cluster never accepts an image that bypassed the workflow.
I draw the line at admission. The build fails on new high or critical CVEs introduced by the diff; the admission webhook blocks any image that is unsigned, lacks an SBOM, or violates Pod Security Standards. Existing CVEs alert the on-call without breaking the release train.
The largest operational cost in container security testing is triaging false positives. Three controls, in order, drop the queue size most.
A VEX statement is a machine-readable assertion (affected, not_affected, fixed, under_investigation) that filters CVEs the vendor has triaged as non-exploitable. CISA's 2023 VEX guidance defines the schema. Scanners that read VEX (Trivy --vex, Grype --vex-documents) drop suppressed findings from the queue.
Reachability scoping uses eBPF runtime correlation to mark CVEs in code paths the workload never executes as low priority. Cilium Tetragon, Sysdig Secure, and Datadog Cloud Security all produce reachability data. A 9.8 CVSS finding in a function the binary does not link is operationally low.
CISA's Known Exploited Vulnerabilities catalog lists CVEs under active exploit. Pair it with EPSS for a probability-of-exploit score. A KEV-listed CVE with EPSS ≥ 0.7 jumps to the top of the queue regardless of CVSS base score; everything else rides the normal cadence.
Auditors expect a one-to-one mapping from the testing pipeline to named control numbers. See Minimus alignment with NIST SP 800-190 for the full mapping; the table below names the controls most often cited per stage.
Map each control to a generated artifact (SBOM, Cosign attestation, Kyverno admission log, and Falco alert) so the 3PAO sees evidence per digest, not vendor claims.
In the regulated clusters I have audited, these ten practices separate working programs from theater.
Three patterns show up in nearly every failed audit I have walked.
A passing Trivy scan only proves the image had no known CVEs at the moment it ran. It says nothing about admission policy, runtime behavior, or zero-days disclosed an hour later.
Teams that publish a CVE dashboard without VEX, KEV, or EPSS context end up triaging hundreds of findings no attacker will ever use. The triage cost exceeds the remediation cost.
A clean image deployed with privileged: true, a mounted Docker socket, and runAsUser: 0 is one T1611 escape away from compromise. IaC and admission tests are not optional.
Minimus provides hardened container images intended to reduce unnecessary packages and inherited build-time vulnerability findings. This may reduce vulnerability-management workload, but it does not automatically reduce admission-policy violations or behavioral runtime alerts, which depend on deployment configuration, enabled policies, workload activity, and sensor tuning. Verify the exact SBOM, VEX, signature, remediation-policy, and vulnerability-intelligence claims before publication. Any comparative reduction figures should be labeled as vendor-reported and accompanied by a reproducible methodology; see Minimus vulnerability intelligence. Browse the gallery at images.minimus.io or read the platform docs at docs.minimus.io.
Container security testing is the practice of validating a containerized workload across five stages: pre-commit, build, registry, admission, and runtime. The scope covers the image, its dependencies, its deployment manifests, and its runtime behavior. The program maps to NIST SP 800-190 §4.1 and §4.4 and uses a layered toolchain such as Hadolint, Trivy, Cosign, Kyverno, and Falco to enforce policy per stage.
Container vulnerability scanning is the build-time slice that compares an image's SBOM against CVE feeds. Container security testing is the program-level umbrella that adds pre-commit linting, registry signing, admission policy, and runtime detection. Scanning alone misses everything outside the image filesystem.
Scan newly built images before promotion, scan registry pushes or releases according to the delivery workflow, and periodically re-evaluate deployed image digests as advisory data changes. The appropriate frequency should reflect release cadence, exposure, asset criticality, and compliance requirements. The image is static after build; the CVE feed is not. 77.6% of DevSecOps teams report weekly-or-faster scans per the 2024 SANS DevSecOps Survey.
A typical GitHub Actions, GitLab CI, or Argo Workflows pipeline runs build, scan, sign, push, and deploy in order. The build fails on new high or critical CVEs; an admission webhook (Kyverno or OPA Gatekeeper) blocks any image at deploy time that is unsigned or violates Pod Security Standards.
Build-time scanners cannot detect zero-days by definition; there is no CVE record to match. Runtime sensors such as Falco, Tetragon, and Tracee can detect zero-day exploitation by flagging anomalous syscalls, processes, or network flows even when the underlying CVE has no public advisory. Pair scanning with runtime detection to cover both classes.
.svg)
.svg)
.svg)
.svg)
