A financial services organization is implementing a CI/CD pipeline using Cloud Build and Artifact Registry for containerized microservices. The security team establishes a strict shift-left security policy: All container images must be analyzed for Common Vulnerabilities and Exposures (CVEs) before they are stored in Artifact Registry. The build pipeline must immediately terminate and block repository upload if any vulnerabilities classified as CRITICAL or HIGH severity are identified. The vulnerability scanning process must integrate natively within Cloud Build without publishing untrusted images to the remote registry. Which pipeline orchestration strategy should the security engineer implement in cloudbuild.yaml?

Execute an on-demand scan using `gcloud artifacts docker images scan` on the locally built container image, evaluate the findings with `gcloud artifacts docker images list-vulnerabilities`, and fail the build step prior to executing `docker push` if target severities are detected.: ### What On-Demand Scanning with Cloud Build Is **On-Demand Scanning (ODS)** is a feature of **Artifact Analysis** that allows developers and automated build pipelines to initiate vulnerability scans on local container images before pushing them to a container repository. Unlike automated registry scanning, which triggers only after an image is uploaded, On-Demand Scanning allows scanning directly within the **Cloud Build** workspace. ### How It Meets the Requirements - **Pre-upload scanning**: In `cloudbuild.yaml`, the image is built locally using `docker build`. The build pipeline calls `gcloud artifacts docker images scan` against the local image tag, generating an on-demand scan resource without requiring the image to be uploaded to **Artifact Registry**. - **Vulnerability evaluation and pipeline gating**: The subsequent build step extracts the scan ID and calls `gcloud artifacts docker images list-vulnerabilities` with a filter for `vulnerability.effectiveSeverity`. By checking for regular expression matches against `CRITICAL|HIGH`, the script exits with code `1` if matched, terminating the Cloud Build execution. - **Blocking repository upload**: Because Cloud Build steps execute sequentially by default, failing the severity-check step prevents the subsequent `docker push` step from ever running, ensuring no vulnerable artifacts reach the registry. ### Key Advantages and Capabilities - **Shift-Left Enforcement**: Catches known **CVEs** in both operating system and language packages at the earliest possible stage of the delivery lifecycle. - **Granular Severity Thresholds**: Enables customized blocking rules (such as `CRITICAL`, `HIGH`, or `MEDIUM`) tailored to organizational compliance policies. - **Zero Registry Footprint for Failed Builds**: Prevents vulnerable images from ever polluting artifact repositories or triggering downstream deployment webhooks. - **Detailed Provenance and Auditability**: Integrates scanning reports and scan IDs directly into build workspace logs. ### Why This Is Optimal This approach natively satisfies shift-left security requirements by scanning the artifact inside the build execution environment and conditioning repository publication on passing vulnerability thresholds.

Cloud Build On Demand Scanning Cve Block Push | Professional Cloud Security Engineer

Cloud Build On Demand Scanning Cve Block Push

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A financial services organization is implementing a CI/CD pipeline using Cloud Build and Artifact Registry for containerized microservices. The security team establishes a strict shift-left security policy:

All container images must be analyzed for Common Vulnerabilities and Exposures (CVEs) before they are stored in Artifact Registry.
The build pipeline must immediately terminate and block repository upload if any vulnerabilities classified as CRITICAL or HIGH severity are identified.
The vulnerability scanning process must integrate natively within Cloud Build without publishing untrusted images to the remote registry.

Which pipeline orchestration strategy should the security engineer implement in cloudbuild.yaml?

Execute an on-demand scan using gcloud artifacts docker images scan on the locally built container image, evaluate the findings with gcloud artifacts docker images list-vulnerabilities, and fail the build step prior to executing docker push if target severities are detected.

Deploy the container image to Google Kubernetes Engine (GKE) and enforce a Binary Authorization policy requiring vulnerability attestations to block runtime pod scheduling.

Upload the image to Artifact Registry to trigger Automatic Scanning, subscribe a Cloud Function to the gcr Pub/Sub topic, and delete the image asynchronously if CRITICAL or HIGH vulnerabilities are reported.

Push the image to Artifact Registry, execute gcloud container images describe --show-package-vulnerability in a post-build step, and initiate a pipeline rollback if CVEs exceed policy thresholds.

Professional Cloud Security Engineer

Cloud Build On Demand Scanning Cve Block Push

Related questions