How Does Container Security Scanning Fit CI/CD?

Container security scanning checks the built image by inspecting image layers, package databases, manifests, and filesystem contents, then compares discovered components against known vulnerability databases. Scanners read directly from the image filesystem before runtime, so the container does not need to be running.

Why Container Scanning Belongs in Every Pipeline

Engineers building container images inherit image-layer risk from packages and commands they never wrote. A public base image carries OS packages with their own CVEs, application dependencies drift between builds, and a stray RUN command can hardcode an API key into a persistent layer. That puts the relevant control boundary at the image artifact before application code runs.

Container scanning addresses this by analyzing the built artifact directly. The scan inspects dpkg, rpm, and apk package databases for OS CVEs and parses language manifests for vulnerable dependencies. It also flags secrets or malware embedded in image layers. Because scanners work on images at rest before deployment, they produce reproducible checks against published threats without executing code.

This guide covers detection categories, open-source and commercial tools, and pipeline patterns for GitHub Actions, GitLab CI, Jenkins, and CircleCI. It also covers severity thresholds, false positive handling, and Kubernetes admission control. For lifecycle coverage, security practices still need repository, dependency, image, and runtime controls. Once findings surface, remediation often spans multiple services and repositories, which is where Augment Cosmos, our unified cloud agents platform for running agents across the software development lifecycle, comes in. Cosmos ships Reference Experts such as Deep Code Review, PR Author, and Incident Response that can take a container-scan finding, open a fix PR, and route review before human sign-off.

What Container Security Scanning Detects

Container security scanning detects seven image-risk categories by inspecting operating system packages, application manifests, image layers, and deployment configuration before a container runs. Each category maps to a different source of risk in the container build process.

• OS package / image layer CVEs: Scanners find flaws in base OS packages such as Ubuntu, Alpine, and Red Hat by scanning dpkg, rpm, and apk databases.
• Application dependencies: Scanners detect security issues in language-specific libraries such as npm, pip, and Maven through manifest files.
• Configuration weaknesses: Scanners flag root execution, unnecessary exposed ports, excessive privileges, and debugging interfaces.
• Embedded secrets: Scanners identify API keys, passwords, and certificates hardcoded into image layers.
• Malware: Scanners look for malicious code, backdoors, or crypto miners injected into images.
• IaC misconfigurations: Scanners check Dockerfiles, Kubernetes manifests, and Terraform files.
• License issues: Scanners detect non-compliant open-source licenses on an opt-in basis.

NIST SP 800-190 groups primary image risks around Image Vulnerabilities, Image Configuration Defects, Embedded Malware, Embedded Clear Text Secrets, and Use of Untrusted Images.

Static Scanning Versus Runtime Monitoring

Static image scanning analyzes container images at rest before deployment by comparing image contents with published vulnerability data. It does not execute code, so it cannot detect runtime exploit behaviors. Runtime monitoring covers the post-start boundary by catching configuration drift, exploit attempts, and behavioral anomalies that emerge after deployment.

How Container Scanning Differs from SAST and SCA

Container scanning analyzes the built image across layers, SAST examines source code for insecure patterns, and SCA parses package manifests for vulnerable open-source dependencies. Each check targets a different artifact in the software supply chain, so teams that treat them as complementary controls close coverage gaps that any one check leaves behind. The table below shows where each control sits and what it misses on its own.

SAST examines proprietary code for vulnerabilities before and during development. SCA identifies vulnerabilities, licensing risks, malicious packages, and compliance issues in open-source dependencies. Container scanning adds coverage for OS-level CVEs, embedded malware, hardcoded secrets, and container-specific misconfigurations. Teams comparing source-level checks against scanner gates can review our companion breakdown of static analysis tooling to see how each layer fits with the others.

Container Scanning Tools Covered in 2026

Container scanning tools differ by scan target, data source, and lifecycle stage. Teams compare Trivy, Grype, Clair, Snyk Container, Docker Scout, Aqua, Prisma Cloud, and Sysdig Secure by mapping each tool to image CVEs, SBOMs, IaC, and runtime coverage. The scanner table below compares eight tools across those categories.

Teams that need coverage across CVEs, IaC, secrets, Kubernetes, and runtime signals can pair scanners. Trivy covers IaC, secrets, and Kubernetes, while Grype adds SBOM-based CVE matching.

Open-source scanner selection depends on whether the gate needs broad policy coverage, SBOM-based matching, or registry indexing.

Trivy

Trivy container scanning combines image CVE detection, IaC checks, secret scanning, and Kubernetes analysis through Aqua-maintained vulnerability databases. CI/CD pipelines can use it for pre-deployment checks across container images, filesystems, Git repositories, Kubernetes clusters, IaC manifests, secrets, and Dockerfile misconfigurations. Trivy's scope maps to its use in GitLab Container Scanning, Artifact Hub, and Harbor.

Trivy supports major OS distributions and language ecosystems through the GitHub Advisory Database, OSV, and language-specific advisories. Its vulnerability database rebuilds every 6 hours, with the Java index built once daily. Trivy prioritizes precision and aims to keep false positives low, sometimes at the cost of false negatives. One limitation is that Trivy does not support third-party or self-compiled packages and binaries.

Teams evaluating Trivy in 2026 should also account for the supply-chain compromise tracked as CVE-2026-33634. The incident began as a late-February 2026 breach that was publicly disclosed and rotated on March 1, but the credential rotation was not atomic. That gap let a threat actor return on March 19, 2026 to publish a malicious v0.69.4 release, force-push 76 of 77 tags in aquasecurity/trivy-action, and replace all 7 tags in aquasecurity/setup-trivy. Malicious v0.69.5 and v0.69.6 Docker Hub images followed on March 22, 2026. Aqua has since removed the malicious artifacts and republished safe releases, with known-safe references at Trivy v0.69.3 or earlier, trivy-action v0.35.0, and setup-trivy v0.2.6. The takeaway for CI/CD gates is to pin the action to a full commit SHA rather than a mutable version tag.

Grype

Grype container scanning focuses on vulnerability detection for container images and filesystems. It generates an SBOM with Syft, then matches components against advisory data to produce image CVE results. Grype matches components against data from the GitHub Advisory Database, NVD, and distro-specific sources, ingesting the OSV schema natively as of DB schema v6.

Grype outputs table, JSON, SARIF, and CycloneDX formats. Its scope is tighter than Trivy: Grype focuses on vulnerability detection, while Trivy also handles IaC misconfigurations, secret detection, and Kubernetes scanning. Anchore describes Grype's shift from CPE-based matching to the GitHub Advisory Database as a false-positive reduction effort in its test data.

Clair

Clair registry scanning performs static analysis of OCI and Docker images through a microservices architecture. Registry deployments use it for vulnerability indexing before teams pull or deploy images. It draws from Alpine SecDB, AWS UpdateInfo, Debian OVAL, Oracle OVAL, RHEL OVAL, SUSE OVAL, Ubuntu OVAL, and Pyup.io for Python. Clair ships with Quay integration. That integration powers the Container Health Index and Red Hat OpenShift via the Container Security Operator.

Commercial Platforms

Commercial container security platforms extend vulnerability management beyond image CVE scanning. The table separates these platforms by whether they provide automated fixes, IaC policy checks, runtime protection, or multi-cloud coverage, with capability boundaries varying by product.

Snyk Container scans images for OS-level and application-level vulnerabilities, recommends base image upgrades, and opens automated fix pull requests. Snyk pricing starts at $0/month for a free tier limited to 100 container tests, with Team plans starting at $25/month per contributing developer.

Docker Scout compiles an SBOM inventory and matches it against a continuously updated database, with a maximum 10 GB image size for analysis unless the image carries an SBOM attestation. Scout and Trivy differ by operating model. Docker Scout emphasizes the Docker environment and fix recommendations, while Trivy emphasizes breadth, zero cost, and no vendor lock-in, as described in OneUptime's side-by-side comparison.

Scanner Divergence Is Real

Scanner divergence affects container security gates because different databases, matching techniques, and naming schemes can produce different results for the same image. Database naming can also add confusion when vulnerability ecosystems use GHSA, CVE, and vendor-specific identifiers for overlapping findings. Treat any single scanner's output as partial evidence.

Integrating Container Scanning into CI/CD Pipelines

Engineers add container scanning to their CI/CD workflows by placing scan steps at build, registry, pre-deployment, and runtime stages, then failing the build when findings exceed a severity threshold. A four-stage control model scans the image before and after registry entry, gates deployment on policy results, and adds runtime monitoring for behavior that static scans cannot observe.

Snyk's documentation advises teams to run a container scan as a separate build step from the Snyk Open Source application SCA test. This separates container and OS failures from application dependency failures.

GitHub Actions

GitHub Actions container scanning runs Trivy or Snyk after image build and before registry push. This turns image vulnerability results into a CI/CD gate before artifacts reach production registries. The official Trivy GitHub Action lives at aquasecurity/trivy-action, and Snyk provides a snyk/actions/docker action. Snyk's guidance is to run snyk container test after building the image and before pushing it. The pipeline breaks if the scan finds vulnerabilities. Trivy supports SARIF output, which teams can upload to the GitHub repository Security tab and route alongside their existing AI code checker for GitHub Actions setup. In the wake of CVE-2026-33634, pin these actions to full commit SHAs rather than mutable @vX.Y.Z tags.

GitLab CI

GitLab 15.0+ includes free Trivy integration via a single include line. One pattern runs a reporting scan with --exit-code 0 to generate gl-container-scanning-report.json, then runs an enforcing scan with --exit-code 1 --severity $SEVERITY_THRESHOLD --ignore-unfixed. The --ignore-unfixed flag suppresses vulnerabilities that have no available fix.

Jenkins and CircleCI

Jenkins and CircleCI container scanning gates use post-build Trivy or Snyk steps with severity thresholds to block vulnerable images before registry push. A Jenkins gate can run a non-failing scan for LOW/MEDIUM/HIGH findings and a failing scan for CRITICAL.

CircleCI supports a community Trivy Orb, native install via curl, and the snyk/snyk@2.2.0 orb. A Snyk-based pipeline places the scan after build but before push, using severity-threshold: high and fail-on-issues: true to block the registry push when high or critical findings appear.

CI/CD scanner placement stays consistent across systems even when the syntax differs. The table below maps the same control decision across four common CI systems.

Configuring Pass/Fail Gates and Severity Thresholds

An AI code governance framework uses a tiered severity model: hard-block on critical findings, apply count-based thresholds on high findings, and warn-only on medium and below. The model creates clear release behavior. Critical findings stop releases, high findings are capped, and medium or lower findings create visibility without blocking.

NIST SP 800-190 requires configuring gates at each build and deployment stage with rules that can prevent image progression when vulnerabilities exceed selected CVSS ratings. The actions below define the standard tiered model.

• Critical: hard block, immediate pipeline failure
• High: configurable count-based threshold
• Medium: warnings only, create tickets for tracking
• Low/Unknown: log for periodic review, do not block

A severity policy blocks critical flaws in base images while medium-risk issues create warnings. This balances developer velocity with enforceable governance.

Avoiding Velocity Bottlenecks

Container-scan velocity control uses gradual threshold tightening and net-new gating to reduce inherited vulnerability debt without stopping all builds on day one. Start with looser thresholds, fail the pipeline only for critical issues initially, and tighten the rules over time. Net-new gating adds another lever: the scanner fails only on vulnerabilities introduced by the current change, which prevents new security debt without halting all development.

Scan timing also matters. Parallel execution and caching for container layers and dependency indexes keep scanner checks from becoming a release bottleneck. Production images already in the registry warrant daily rescans because new CVEs surface between pipeline runs.

Velocity control works best when gate behavior is clear before enforcement begins. The controls below trade off strictness against release throughput as the program matures.

Handling False Positives and Exceptions

Container-scan false positive handling uses documented exceptions, expiry dates, and fixability checks. These controls keep CI/CD gates enforceable without hiding unresolved risk. Documented exceptions keep the security decision visible when teams choose not to fix a finding, so immediate remediation of every issue is no longer required.

Backported packages are a common false positive source. Scanners typically only see the upstream Python package version number, not the distribution's security-patched version. Fixability checks keep CI/CD gates focused on remediable findings.

Exception handling should preserve enough context for future review while keeping the active gate focused. The inputs below map each exception mechanism to what it changes on the gate and what audit signal it leaves behind.

Managing Triage, Suppression, and Remediation

Triage combines three scoring inputs, exploitability data, and VEX-based suppression to filter raw findings down to actionable issues. Documented suppression gives teams a way to handle large alert volumes without hiding unresolved risk.

Three scoring inputs guide prioritization. CVSS provides a general severity score, EPSS predicts exploitation likelihood, and CISA KEV lists actively exploited CVEs. KEV membership signals urgent remediation. GitLab 17.9 added EPSS, KEV, and CVSS support in Vulnerability Reports.

Triage signals separate severity, likelihood, and observed exploitation so teams can prioritize each scanner finding on its own merits. Each signal in the table below adds a different lens on the same CVE.

Once triage identifies a KEV-tagged finding that needs a fix, the Cosmos Incident Response Reference Expert can pick up the CVE, gather affected services, and hand a scoped remediation task to the PR Author Expert, which drafts the fix and routes it to Deep Code Review before a human approver signs off.

VEX for Suppressing Non-Actionable Findings

VEX (Vulnerability Exploitability eXchange) is a machine-readable advisory format that communicates whether a known vulnerability is exploitable in specific software. CISA defines four required product statuses: NOT AFFECTED, AFFECTED, FIXED, and UNDER INVESTIGATION. VEX gives security platforms a structured way to suppress findings when the application cannot reach vulnerable code or a mitigation already exists.

Trivy consumes VEX documents directly, for example trivy sbom debian11.sbom.cdx --vex trivy.vex.cdx. One documented Trivy limitation is that it only considers the last VEX statement when multiple statements reference the same CVE with different Package URLs in CycloneDX VEX files.

Handling Unfixable CVEs

Unfixable CVE handling uses scanner flags and documented ignore rules to keep CI/CD gates focused on remediable risk while preserving an audit trail. Trivy's --ignore-unfixed flag hides vulnerabilities with no available fix. End-of-life operating systems may return zero vulnerabilities despite remaining vulnerable. For those cases, the --exit-on-eol flag fails the scan with a non-zero exit code.

For documented suppression, Trivy's .trivyignore.yaml supports path-specific and PURL-specific rules, expiry dates, and justifications. Grype offers equivalent ignore rules in .grype.yaml keyed by CVE ID, package name, version, and fix state.

Unfixable CVE controls should separate scanner noise from release-blocking risk while keeping the audit trail intact. The controls below cover both scanner flags and the ignore-file formats that document suppressions.

Base Image Strategies

Base image strategy limits scanner input by minimizing the packages and runtime components shipped inside production images. Distroless images narrow the scanned artifact by shipping only the application and its runtime dependencies. They omit package managers, shells, and other programs expected in a standard Linux distribution, which improves the signal to noise of scanners. The caveat, as of 2026, is that even well-maintained distroless images ship with CVEs traceable to required language runtimes and C library dependencies.

Sifting findings from suppressed noise across many images requires teams to understand how base image changes affect services that share runtimes and dependencies. On Cosmos, tenant memory persists patterns and corrections across sessions, so once a shared runtime bump is coordinated once, agents apply the same blast-radius reasoning to the next base-image change without re-learning the service graph.

Base image decisions reduce scanner input, but they do not remove the need for triage. The approaches below trade scanner surface for other operational costs.

Enforcing Scans at the Registry and Kubernetes Admission Layer

Registry scanning catches vulnerabilities in stored images while Kubernetes admission controllers block non-compliant images at deploy time. An admission controller intercepts requests to the Kubernetes API server before the resource persists. This creates a final gate before any pod runs.

Registry and admission controls enforce the same image decision at different points in the deployment path. The table below shows where each layer sits and what it cannot see.

Registry-Level Scanning

Registry-level scanning continuously analyzes stored container images through native registry scanners and policy checks. It can prevent teams from pulling or promoting vulnerable artifacts when registry policy supports that control. Harbor provides static vulnerability analysis through Trivy, and teams enable it at install time by appending --with-trivy. Harbor's deployment security feature can block vulnerable pulls if Harbor discovers vulnerabilities. Teams configure this through the Prevent vulnerable images from running option.

Cloud registries offer native scanning. Amazon ECR provides basic scanning that sources more than 50 data feeds. It also provides enhanced scanning with Inspector integration for continuous rescans. Google Artifact Registry offers built-in scanning and integrates with Binary Authorization for deploy-time enforcement. Microsoft Defender for Containers performs agentless vulnerability assessment of registry images and running containers, providing daily rescans across ACR, ECR, GAR, GCR, Docker Hub, and JFrog Artifactory.

Kubernetes Admission Control

Kubernetes admission control enforces container security policy at deploy time by using validating and mutating webhooks to accept, reject, or modify resources before persistence. Kyverno runs as a dynamic admission controller that receives validating and mutating admission webhook callbacks from the Kubernetes API server and applies matching policies. Its failureAction field controls enforcement: Enforce blocks violating resources while Audit logs violations but allows creation. Kyverno's verifyImages rule checks attached signatures and mutates matching images to add the image digest. This keeps the deployed image version aligned with the scanned version.

OPA Gatekeeper offers an alternative approach as a customizable admission webhook for Kubernetes that enforces policies executed by the Open Policy Agent. JFrog provides an External Data provider for Gatekeeper that queries JFrog for image metadata such as vulnerability scan results. The cluster can then refuse images that failed their registry scan.

Admission tooling differs by policy language and metadata source, and both approaches enforce image decisions before persistence. The table below compares the two most common admission options and the JFrog metadata bridge that connects them to registry scan results.

The Registry-Runtime Coverage Gap

Registry and admission scanning stop at deployment-time evidence: known CVEs and configuration state. Runtime behavioral monitoring from tools like Falco, Tracee, or Sysdig addresses this boundary by observing container behavior after the container starts running.

Start with a Two-Scanner Gate Before Your Next Release

Container scanning remains enforceable when teams manage noise while keeping the gate strong. Start this sprint by adding a Trivy scan to the build pipeline with --exit-code 1 --severity CRITICAL --ignore-unfixed, then add a second scanner and VEX suppression as the program matures.

Single-scanner coverage can miss findings, and false positives and unfixable CVEs can erode developer trust in reports. Layering scanner outputs with VEX-based suppression, tiered severity gates, and registry rescans keeps release-blocking risk separate from scanner noise. Once the gate is stable, Cosmos experts can pick up the remaining remediation load, with Deep Code Review, PR Author, and Incident Response coordinating fixes across services so the human review point moves from every PR down to a smaller set of steering decisions.

Frequently Asked Questions

Related Resources

• Autonomous Code Review Platforms for Enterprise Teams
• 10 Open Source AI Code Review Tools Tested on a 450K-File Monorepo
• 12 Best Open Source Code Review Tools in 2026
• 13 Best AI Coding Tools for Complex Codebases in 2026
• 8 Best AI Coding Assistants (Updated May 2026)