Integrating Container Image Scanning Into CI/CD Without Blocking Every Build

Every container image has three vulnerability layers with different ownership and different remediation paths:

Layer 1: The OS base image. The FROM directive in the Dockerfile pulls an official image (ubuntu:22.04, debian:bookworm-slim, alpine:3.19, or a runtime-specific image like node:20-alpine). The OS base image contains the operating system, package manager, core utilities, and an inherited set of installed packages -- including vulnerabilities in those packages. The application team chose which base image to use but does not maintain it. Remediation requires updating to a newer version of the base image or switching to a more minimal base image (Alpine vs. Debian, for example).

Layer 2: OS packages installed in the Dockerfile. Any RUN apt-get install, RUN apk add, or equivalent command installs additional OS packages that inherit vulnerabilities from their package versions. The application team owns these choices -- if the Dockerfile installs curl, bash, or git for build-time tasks and those packages have CVEs, the team can remove them from the final image or use multi-stage builds to separate build-time tools from the runtime image.

Layer 3: Application-level dependencies. The npm packages, Python pip packages, Maven/Gradle dependencies, or Go modules that the application imports. These are directly controlled by the application team through package.json, requirements.txt, pom.xml, or go.mod. Vulnerabilities in this layer are the same as standard SCA findings in the application's dependency tree.

Effective scanner configuration treats these three layers differently: Layer 1 findings route to a base image update process, Layer 2 findings are application team responsibility with a remediation path of package removal or version update, and Layer 3 findings integrate with the application's existing SCA workflow.

Scanner threshold configuration determines when a scan result fails the pipeline versus when it produces an advisory report that does not block the build.

A threshold configuration that produces trusted results and does not get disabled:

Fail the build on: findings in Layer 2 (OS packages the application team installed) or Layer 3 (application dependencies) with CVSS 9.0 or above AND EPSS above 0.1 (10% exploitation probability). This combination targets findings that are both theoretically severe and actively targeted in practice.

Warn but do not fail on: findings in Layer 2 or Layer 3 with CVSS 7.0 to 8.9, or CVSS 9.0 with EPSS below 0.1. These appear in the pipeline output and in the scan report but do not block deployment. The team sees them and can schedule remediation without being blocked from shipping.

Suppress and report separately on: Layer 1 (base image) findings. These are surfaced in a separate base image vulnerability report routed to whoever owns the base image selection and update process -- typically a platform or infrastructure team, not the application development team.

Grype and Trivy both support this configuration. Trivy supports severity filtering (--severity CRITICAL) and EPSS threshold filtering with the --ignore-unfixed flag (which skips findings with no available fix). Grype supports custom ignore rules in .grype.yaml that can target specific packages, package types, or CVEs. Snyk Container provides reachability filtering similar to its SCA product for application-layer dependencies.

OS base image vulnerabilities are the largest source of scanner noise and the least actionable for application development teams. The fix is almost always "update the base image to a newer version" -- a change that is the development team's responsibility but depends on the base image maintainer publishing an update.

Three strategies for managing base image vulnerability volume:

Pin to minimal base images. The larger the base image, the more packages it contains, and the more vulnerability surface it carries. Switching from node:20 (Debian-based, ~300MB) to node:20-alpine (Alpine-based, ~50MB) typically reduces the package count from 100+ to under 30, reducing scanner findings by 60 to 80%. Alpine uses musl libc and busybox instead of the full GNU toolchain, which also reduces the historical CVE count significantly.

Use distroless base images where possible. Google's distroless images contain only the runtime and its direct dependencies -- no shell, no package manager, no utilities. The result is near-zero OS-layer scanner findings because there are almost no OS packages to have vulnerabilities. Distroless images are available for Java, Python, Node.js, and Go. Caveat: no shell means debugging and interactive access are not possible in distroless containers, which requires tooling changes for incident response.

Automate base image updates. Dependabot, Renovate, and similar tools support automated pull requests for base image updates when a newer version is available. Configuring weekly automated base image update PRs means the development team always uses a recent base image without requiring manual monitoring of upstream changes.

Even well-configured thresholds produce some scanner failures for findings the team has evaluated and accepted -- a CVE with no available fix, a vulnerability in a library feature the application never uses, or a finding in the base image layer that cannot be addressed until the upstream base image publishes a fix.

Both Trivy and Grype support ignore files that suppress specific findings from the scan results. Trivy uses a .trivyignore file at the repository root. Grype uses a .grype.yaml with an ignore section. Each suppressed finding entry should include: the CVE ID, the reason for suppression, the date added, and an expiration date (at which point the entry is automatically reconsidered).

The expiration date is the key discipline mechanism. Suppress a finding indefinitely and it becomes background noise that hides real risk over time. Suppress it for 90 days and the team is forced to re-evaluate it when the suppression expires: has a fix been published? Has the EPSS score changed? Is the finding still in the application?

The review process for expiring suppressions:

• Query the allow-list for entries expiring in the next 30 days
• For each entry: confirm the CVE is still present in the image, check whether a fix is now available, check whether the EPSS score has changed since suppression
• Either renew the suppression with an updated justification or remove it and treat the finding as active

This process prevents allow-lists from becoming permanent suppression archives that accumulate over time without review.

Container image scanning should run at two points in the CI/CD pipeline:

Pre-push scan (in the build job). Run the scanner against the locally built image before it is pushed to the registry. This catches findings at the earliest point and prevents vulnerable images from entering the registry. The scan runs as a pipeline step after the docker build command and before docker push. For GitHub Actions: use the aquasecurity/trivy-action or anchore/scan-action with the image-ref parameter pointing to the locally built image. For GitLab CI: use the container_scanning template or a custom trivy job in the pipeline YAML.

Registry scan (continuous, separate from the build pipeline). Run a scheduled scan against all images in your container registry at least daily. New CVEs are published daily -- an image that was clean last week may have a critical finding this week without any code change. AWS ECR Enhanced Scanning (using Inspector), Google Artifact Registry Vulnerability Scanning, and Azure Container Registry scanning all support continuous registry scanning. These scans produce findings that are routed to the image owner (identified by the image tag or repository name convention) rather than blocking any pipeline.

Scan the final runtime image, not the build image. In multi-stage Dockerfiles, the first stage may contain build tools (compilers, test frameworks, build-time dependencies) and the final stage contains only the runtime application. Scan the final stage image -- the one that runs in production. Scanning the build stage generates findings for tools that never reach production and creates unnecessary noise.

For Kubernetes deployments: integrate admission control scanning (using Trivy Operator or similar) that scans images at pod creation time against the current CVE database, catching vulnerabilities in images that were clean when built but have since had new CVEs published against them.

Even with well-calibrated thresholds, pipeline blocking scan failures will occur. The escalation policy determines what happens next and prevents both "block everything indefinitely" and "approve everything immediately without review."

A three-path escalation policy:

Path 1: Fix and resubmit (for Layer 2 and Layer 3 findings with available fixes). If the scanner failure is for a finding in a package the application team controls (OS package they installed, application dependency) and a fix is available (updated package version), the expected resolution is: update the package, rebuild the image, resubmit the pipeline. SLA for this path: critical findings blocking a release must be resolved within 24 hours; high severity within 5 business days.

Path 2: Temporary suppression with documented exception (for findings with no available fix or base image findings incorrectly classified by the scanner). If the finding has no available fix or is a base image finding that exceeded the threshold due to scanner miscategorization, the engineer opens an exception request with: the CVE ID, the reason a fix is not currently available, the compensating control (network isolation, input validation, feature flag that disables the vulnerable code path), and the review date. A security team member approves the exception. The finding is added to the allow-list with the expiration date from the exception request.

Path 3: Emergency deployment override (for production incidents where a delayed fix is available). If a production incident requires deploying a build that has a scanner failure and the fix requires more than 24 hours, the pipeline includes an override mechanism requiring dual approval (engineering manager plus security team member) with a mandatory post-deployment remediation ticket created at the time of override. This is the emergency exit that prevents a security scanner from blocking a P0 incident response while maintaining accountability for the vulnerability.