Automated CVE Scanning in CI/CD Pipelines

Manage remediation and reporting of identified vulnerabilities is the process of blocking risky images, sorting findings by severity and fixability, and producing actionable reports from scan metadata. In Google Cloud, Cloud Build (opens in a new tab) builds the image from source code, On-Demand Scanning (opens in a new tab) scans the built image before storage, and Artifact Analysis (opens in a new tab) maintains vulnerability occurrences for images and packages stored in Artifact Registry. The severity gate decides whether the image is pushed to Artifact Registry or the build fails, while scan metadata provides the CVE identity, severity, and fix data needed to patch and rebuild.

1.1Block Vulnerable Images in the CI/CD Pipeline

Blocking vulnerable images in the CI/CD pipeline means Cloud Build only pushes an image to Artifact Registry when On-Demand Scanning finds no vulnerabilities at or above a predefined severity level. The pipeline builds the container image, runs On-Demand Scanning to extract packages and versions, compares findings to the SEVERITY threshold, and pushes only on success. When the threshold is set to CRITICAL|HIGH, the check looks for HIGH vulnerabilities and the more severe CRITICAL vulnerabilities, so either level triggers remediation work.

The build-to-registry flow runs in a fixed order with a hard stop on failure:

1. Build: Cloud Build builds the container image from source code.
2. Scan: On-Demand Scanning extracts packages and versions and analyzes them for vulnerabilities.
3. Severity check: The pipeline compares findings to the SEVERITY value, such as CRITICAL|HIGH.
4. Push or fail: On success Cloud Build pushes the image to Artifact Registry; on failure the scan step exits with non-zero status 1, subsequent build steps do not start, and no image is pushed.

A successful build reports STATUS: SUCCESS with the image reference in Artifact Registry, while a failed build reports Failed vulnerability check and step exited with non-zero status: 1. Because Linux distributions such as debian10:latest and related vulnerability data receive updates on an ongoing basis, the same source can pass on one run and fail on a later run. Remediation therefore means updating the base image or dependent package to a fixed version, rebuilding in Cloud Build, and letting the scan gate verify the fix.

1.2Triage Scan Findings for Actionable Remediation

Triage of scan findings is the sorting of each vulnerability occurrence by identity, severity, and whether a fix exists so owners know what to patch first. Artifact Analysis reports each finding with the data needed to choose between immediate patching, a base-image update, or a temporary compensating control when no fix is available. Findings with fixes point to a version upgrade and rebuild, while findings without fixes require risk acceptance, isolation, or other controls until upstream data changes.

Actionable triage fields for each finding include:

• CVE name: The Common Vulnerabilities and Exposures identifier that links the finding to public vulnerability data.
• Effective severity and CVSS score: The normalized severity and numeric Common Vulnerability Scoring System score used to rank CRITICAL above HIGH and lower levels.
• Fix status: Whether a fix is available, shown in the console as View Fixed when fixed versus View when unfixed.
• Affected package identity: The package name, package type such as MAVEN, version number, and affected location that show exactly what to upgrade.
• Scan summary counts: Totals for vulnerabilities, vulnerabilities with fixes available, vulnerabilities without fixes, and package types scanned.

In the Google Cloud console the vulnerability table lists CVE name, effective severity, CVSS score, fixes when available, containing package name, and package type, with filtering, sorting, and up to 1200 vulnerabilities displayed per page. Selecting a CVE shows details, and selecting View or View Fixed shows occurrence details such as version number and affected location. For On-Demand Scanning results retrieved by scan name, Maven and Linux findings appear together, with Maven findings identified by packageType:MAVEN.

1.3Retrieve and Share Vulnerability Reports

Retrieving vulnerability reports means reading the same Artifact Analysis occurrences through the Google Cloud console, Google Cloud CLI (gcloud CLI), or Container Analysis API depending on automation needs. The console supports interactive triage for one repository, image digest, or package version, while gcloud CLI and the Container Analysis API support pipeline automation and aggregated reporting. All three paths require permission to read scan metadata, including Artifact Registry Reader with Container Analysis Occurrences Viewer and Container Analysis Notes Viewer for package results.

Data flows from the scanner to Artifact Analysis occurrences, then from occurrences to the selected reporting surface. A scan with gcloud artifacts docker images scan returns an operation and a scan resource name such as projects/my-project/locations/us/scans/893c91ce-7fe6-4f1a-a69a-d6ca1b465160, and gcloud artifacts docker images list-vulnerabilities reads vulnerabilities for that scan name. For stored packages, gcloud artifacts versions describe VERSION --location=LOCATION --repository=REPOSITORY --package=PACKAGE --show-package-vulnerability reads the package vulnerability for one version. The API equivalents read projects/PROJECT_ID/occurrences, projects/PROJECT_ID/occurrences:vulnerabilitySummary, and projects/PROJECT_ID/occurrences/OCCURRENCE_ID with a bearer token.

1.4Manage Scan Freshness, Staleness, and Re-scans

Scan freshness management tracks whether Artifact Analysis metadata is still being updated or has become stale or archived based on image pull activity. Artifact Analysis continues to scan images and packages as long as they have been pulled within the last 30 days, so frequently used artifacts keep current vulnerability data. After 30 days without a pull, metadata is no longer updated and results are considered stale, which means reports may miss newly published CVEs. After metadata has been stale for more than 90 days, Artifact Analysis archives it, and archived metadata can be evaluated only by using the API.

An image with stale or archived metadata can be re-scanned by pulling that image, which restarts analysis and can take up to 24 hours to refresh metadata. Packages with stale or archived metadata cannot be rescanned in the same way, so pipeline reports should treat old package findings as unreliable until the package is republished and rescanned. Remediation workflows therefore depend on both the severity gate and freshness: rebuild from an updated base image, push to Artifact Registry to create fresh occurrences, and re-pull or rebuild actively used images so continuous scanning keeps reporting accurate.

Integrating vulnerability scanning tools into CI/CD workflows is the practice of automatically checking container images and language packages for known Common Vulnerabilities and Exposures (CVEs) before they can be deployed. On Google Cloud, Artifact Analysis (opens in a new tab) provides automatic scanning after push and On-Demand Scanning (opens in a new tab) before push, orchestrated by Cloud Build (opens in a new tab) and stored in Artifact Registry. Together they let a pipeline build an image, extract package inventory, match it against vulnerability data, enforce a severity gate, and publish results for review.

2.1Automatic Scanning Compared with On-Demand Scanning

Automatic scanning and On-Demand Scanning differ in when they run and where they block the release. Automatic scanning runs after an image is pushed to Artifact Registry, while On-Demand Scanning runs inside the pipeline before the image is trusted or stored. The pipeline depends on both services: Cloud Build produces the artifact, Artifact Analysis analyzes it, and Artifact Registry holds the result and scan metadata.

When the Artifact Analysis API is enabled, Artifact Analysis automatically begins scanning each new image pushed to Artifact Registry repositories in the project. Scanning for language packages is disabled by default, so the repository owner must explicitly control scanning settings for an individual repository. Choose automatic scanning when the goal is continuous visibility on stored artifacts, and choose On-Demand Scanning when the goal is a pre-push quality gate.

2.2Orchestrating a Blocking Scan in Cloud Build

A blocking Cloud Build pipeline enforces vulnerability policy by treating the scan as a build step that must succeed before the push step runs. The build service account calls the On-Demand Scanning API, waits for analysis, evaluates severity, and only then pushes the image to Artifact Registry. This order creates a trust boundary between untrusted built images and trusted registry images.

1. Build: Cloud Build builds the container image from source code in an early build step.
2. Scan: A later step runs On-Demand Scanning against the built image to extract OS and language packages and initiate remote analysis.
3. Severity check: A check step compares findings against a predefined SEVERITY value, such as CRITICAL|HIGH, and exits with non-zero status if a match exists.
4. Conditional push: Only after the severity check passes does Cloud Build push the image to Artifact Registry; if the check fails, subsequent steps do not start.

When SEVERITY is set to CRITICAL|HIGH, the scanner looks for both HIGH and the more severe CRITICAL findings. A successful build ends in SUCCESS and the image appears in Artifact Registry, while a failed build reports Failed vulnerability check and step exited with non-zero status: 1 with no image pushed. Because public base images such as debian10:latest receive ongoing CVE updates, the same Dockerfile can pass one day and fail the next.

2.3Configuring Scan Scope and Execution

Scan configuration in On-Demand Scanning controls which image is analyzed, where analysis runs, and which package ecosystems are included. Local scans analyze an image on the build worker using REPOSITORY:TAG or REPOSITORY, while remote scans analyze an image already in Artifact Registry and require --remote plus a full HOSTNAME/PROJECT_ID/REPOSITORY_ID/IMAGE_ID URI with tag or digest. The local-extract component of the Google Cloud CLI must be installed for local extraction, and the caller needs the On-Demand Scanning Admin role unless it is the project owner.

The gcloud artifacts docker images scan command supports --location=(us,europe,asia) to select the multi-region where analysis occurs, --async to return an operation instead of waiting, and --additional-package-types=MAVEN to include Java dependencies beyond OS and Go packages. On-Demand Scanning runs in a Linux environment and in macOS and is not supported on Windows. Synchronous execution extracts packages locally, initiates remote analysis, and waits for the operation to complete and return a scan resource name, while asynchronous execution requires polling the long-running operation and then calling list-vulnerabilities with that scan name.

2.4Managing Results, Freshness, and Visibility

Vulnerability results in Artifact Analysis are stored as occurrences linked to an image digest or package version, with CVE name, effective severity, Common Vulnerability Scoring System (CVSS) score, affected package, package type such as MAVEN, and fix availability. Artifact Analysis continues to refresh metadata only while the image or package has been pulled within the last 30 days; after 30 days results become stale and are no longer updated, and after more than 90 days they become archived and can be evaluated only by using the API. Pulling a stale or archived image triggers a rescan, but refreshing metadata can take up to 24 hours.

Results flow from Artifact Analysis to three destinations: the Artifact Registry console shows totals in the Vulnerabilities column and detailed scan results with fix status, the CLI shows occurrences through image and package commands, and the Container Analysis API exposes occurrences and a project-wide vulnerability summary. The Cloud Build Security insights side panel combines build data from Cloud Build with scan data from Artifact Analysis to show Supply-chain Levels for Software Artifacts (SLSA) level, scanned image name and vulnerabilities, Vulnerability Exploitability eXchange (VEX) status, software bill of materials (SBOM), and build details such as builder and logs. A preview layerDetails field can further identify which layer introduced a package by reporting index, diffID, build command such as FROM golang:example_sha256, and base images.

Viewing findings requires Identity and Access Management permissions on the project where Artifact Analysis runs:

• Container Scanner Service Agent to allow the scanning service to operate
• Container Analysis Occurrences Viewer to read vulnerability occurrences
• Container Analysis Notes Viewer to read vulnerability notes
• Artifact Registry Reader to read repositories and images

To populate the Security insights panel, the operator must also enable the Container Scanning API, store the Cloud Build artifact in Artifact Registry, and hold Cloud Build Viewer plus Container Analysis Occurrences Viewer.

Establishing policy enforcement and gating mechanisms is the process of turning vulnerability scan results into a deployment decision that reflects organizational risk tolerance. In Google Cloud, On-Demand Scanning (opens in a new tab) provides a pipeline gate that fails a build on severity, while Artifact Guard (opens in a new tab) provides centralized vulnerability policies that are enforced at build, registry, and runtime. Together they prevent vulnerable container images from progressing to production environments.

3.1Pipeline Gating With On-Demand Scanning and Cloud Build

A Cloud Build pipeline gate builds a container image from source, scans it with On-Demand Scanning, evaluates severity, and pushes to Artifact Registry only when the image passes. The gate is implemented as a dedicated severity-check build step that queries the scan for vulnerabilities at or above a configured SEVERITY value, such as CRITICAL|HIGH. When the threshold is matched, that step exits with non-zero status, subsequent build steps do not start, and Cloud Build does not push the image to Artifact Registry.

The ordered gate behaves as follows:

1. Build: Cloud Build builds the container image from source code.
2. Scan: On-Demand Scanning analyzes the image for system and language-package vulnerabilities and returns a scan resource name.
3. Severity check: A gcloud build step evaluates the scan against the severity threshold and fails the build on a match.
4. Publish: Only when no matching vulnerabilities are found does the build reach SUCCESS and push the image to Artifact Registry.

When SEVERITY is set to CRITICAL|HIGH, On-Demand Scanning checks for both HIGH and the more severe CRITICAL findings. A clean result allows the push to proceed, while a failed vulnerability check produces a build error and stops the pipeline before publication. This enforces organizational risk tolerance directly in the continuous integration and delivery (CI/CD) pipeline, so remediation happens before an artifact is stored.

3.2Centralized Vulnerability Policies With Artifact Guard

Artifact Guard is the Security Command Center service that detects and manages container image vulnerabilities through centralized, configurable security policies. A security administrator defines one policy that applies across CI/CD, registry, and runtime scopes, and Artifact Guard evaluates every container image defined as an artifact against that policy. Findings from all scopes are combined into a single view in Security Command Center, with a machine-readable software bill of materials (SBOM) used to map image components to Common Vulnerabilities and Exposures (CVEs).

Artifact Guard policies express risk tolerance through four peer controls:

• Severity-threshold blocking: Prevent pushing or deploying images that contain vulnerabilities above a threshold, for example blocking HIGH or CRITICAL vulnerabilities.
• Package and CVE allow and deny lists: Explicitly allow or deny specific software packages, package versions, or CVE identifiers regardless of severity.
• Exception grace periods: Grant temporary exceptions for specific CVEs so teams can continue deploying while fixes are developed without permanently weakening the policy.
• Centralized findings: Aggregate scan results from CI/CD pipelines, Artifact Registry repositories, and running Google Kubernetes Engine (GKE) clusters for consistent evaluation.

3.3Enforcement Points Across the Container Lifecycle

Artifact Guard enforces the same policy intent at three distinct lifecycle stages, each with a different enforcement boundary. Build-time scanning integrates with Cloud Build, GitHub Actions, and Jenkins and fails the build before the image can be published. Registry admission control evaluates images stored in Artifact Registry and depends on Binary Authorization to block non-compliant images from being deployed to GKE clusters. Runtime monitoring continuously evaluates containers already running in GKE for newly disclosed vulnerabilities and enriches policy-violation findings in Security Command Center.

3.4Policy Scoping, Roles, and Continuous Evaluation

Artifact Guard policies apply to three scopes: CI/CD platform, Artifact Registry repository, and GKE cluster runtime. For a pipeline scope, DevOps or platform engineering first creates a connector to the CI/CD environment through CI/CD integration; for repository or cluster scopes, the scope is defined natively during policy configuration. Security administrators own policy definition, DevOps or platform engineering owns connector and admission-controller configuration, and application developers own remediation of vulnerable dependencies identified in failure logs.

Deployment of policy enforcement follows an ordered workflow:

1. Connect the scope: Create a CI/CD connector for Cloud Build, GitHub Actions, or Jenkins, or select the target Artifact Registry repository or GKE cluster.
2. Configure the policy: Define severity thresholds, package and CVE allow and deny rules, and any time-bound CVE exceptions for that scope.
3. Run evaluation: Pipeline builds are evaluated at build time, registry images are evaluated by Binary Authorization at deploy time, and running containers are re-evaluated continuously for new disclosures.

Continuous evaluation matters because vulnerability data changes after deployment. Artifact Analysis refreshes metadata while images have been pulled within the last 30 days, and runtime monitoring in Artifact Guard therefore catches CVEs disclosed after an image was approved. Effective severity, Common Vulnerability Scoring System (CVSS) score, and fix availability from the scan results give administrators the dimensions to tighten thresholds, target specific packages, or grant a grace period without disabling the gate.

Key Facts

• On-Demand Scanning in Cloud Build enforces a severity gate where a match at CRITICAL|HIGH causes the build step to exit with non-zero status 1 and prevents the image from being pushed to Artifact Registry.
• Automatic scanning in Artifact Registry monitors stored images after push, while On-Demand Scanning blocks vulnerable images before push to Artifact Registry.
• Artifact Guard enforces centralized vulnerability policies at build-time scanning, registry admission control with Binary Authorization, and runtime monitoring of GKE containers.
• Artifact Analysis stops updating metadata after 30 days without a pull and archives metadata after more than 90 days stale, with archived metadata available only through the API.