An enterprise organization is designing a secure CI/CD pipeline on Google Cloud to align with the Supply-chain Levels for Software Artifacts (SLSA) framework and mitigate insider risk. The pipeline must satisfy the following security and governance requirements: Prevent unilateral changes: Ensure that no individual developer acting alone can directly merge unvetted source code into production builds. Verifiable build provenance: Build container images in an isolated, centralized service that generates tamper-evident provenance metadata linking the artifact to its exact source repository commit and build steps. Deploy-time policy enforcement: Block the deployment of any container image unless it carries verified attestations confirming mandatory peer reviews and legitimate build provenance. Which combination of controls and architecture should the DevOps team implement?

Require two-person code reviews in the source control system, execute container builds in a centralized build service that automatically generates signed provenance attestations, and enforce deployment policies using Binary Authorization.: What this solution is This architecture combines branch protection rules, centralized verifiable build execution, and deploy-time policy admission controllers to establish end-to-end software supply chain security aligned with the Supply-chain Levels for Software Artifacts (SLSA) framework. How it meets the requirements Prevent unilateral changes: Enforcing mandatory two-person code reviews in source control ensures that every code change undergoes independent verification before merging. This eliminates the risk of an individual developer acting alone to deploy malicious or unauthorized modifications to production systems. Verifiable build provenance: Executing builds in a managed, centralized service (such as Cloud Build) isolates the compilation and packaging environment. The build service generates signed, non-falsifiable provenance metadata that explicitly records the source repository URL, commit hash, build entry points, and output artifact hashes. Deploy-time policy enforcement: Using Binary Authorization introduces an admission control gate on Google Kubernetes Engine (GKE) or Cloud Run. The admission controller verifies cryptographic signatures and attestations against an enterprise policy, ensuring that non-compliant images lacking valid provenance or peer reviews are rejected prior to execution. Key advantages Implements the foundational principles of Google's Binary Authorization for Borg (BAB) and SLSA framework. Mitigates both external supply chain tampering and internal insider threat vectors. Shifting security checks left into the build phase while maintaining non-bypassable enforcement at the deployment choke point. Generates an immutable, auditable trail linking production containers back to reviewed source commits. Why this is optimal Centralizing build execution and binding it to cryptographic attestations evaluated by Binary Authorization creates a zero-trust build and deployment pipeline that prevents compromised developer workstations or untrusted artifacts from entering production.

Binary Authorization with SLSA Provenance and Two-Person Review

Enforcing SLSA Provenance with Binary Authorization

An enterprise organization is designing a secure CI/CD pipeline on Google Cloud to align with the Supply-chain Levels for Software Artifacts (SLSA) framework and mitigate insider risk.

The pipeline must satisfy the following security and governance requirements:

Prevent unilateral changes: Ensure that no individual developer acting alone can directly merge unvetted source code into production builds.
Verifiable build provenance: Build container images in an isolated, centralized service that generates tamper-evident provenance metadata linking the artifact to its exact source repository commit and build steps.
Deploy-time policy enforcement: Block the deployment of any container image unless it carries verified attestations confirming mandatory peer reviews and legitimate build provenance.

Which combination of controls and architecture should the DevOps team implement?

Implement feature flags and blue-green traffic shifting in the deployment pipeline, and configure a Change Advisory Board approval gate in the continuous delivery tool.

Have developers sign container images locally using personal PGP keys following a self-review checklist, push the images to Artifact Registry, and configure automated vulnerability scanning.

Require two-person code reviews in the source control system, execute container builds in a centralized build service that automatically generates signed provenance attestations, and enforce deployment policies using Binary Authorization.

Deploy application code using Cloud Run source-to-container continuous deployment triggers directly from developer feature branches, and rely on Cloud Monitoring alerts for unauthorized deployments.

Explanations

Implement feature flags and blue-green traffic shifting in the deployment pipeline, and configure a Change Advisory Board approval gate in the continuous delivery tool.

What this option is

This approach uses progressive deployment strategies, such as canary or blue-green releases, alongside manual Change Advisory Board (CAB) gate approvals and dynamic feature flag controls inside a Continuous Delivery (CD) orchestrator.

Why it doesn't meet the requirements

Prevent unilateral changes: While CAB gates provide operational review, they typically review release tickets rather than performing line-by-line two-person code reviews at the source commit level.
Verifiable build provenance: Feature flags and blue-green deployments manage traffic routing and rollback mechanics; they do not generate cryptographic build provenance tying container images back to source repositories and build parameters.
Deploy-time policy enforcement: CD approval gates check pipeline metadata within the delivery tool, but they do not enforce platform-level admission control (like Binary Authorization) to prevent out-of-band or direct cluster deployments.

Key limitations

Release orchestrator gates can be bypassed if an actor has direct API access to the target deployment cluster.
Traffic shifting mitigates runtime failure blast radius but does not secure the software supply chain against malicious tampering.
Does not satisfy SLSA requirements for isolated build execution and signed provenance.

This answer would be correct if

The team's primary objective was minimizing end-user downtime during application rollouts and controlling feature experimentation through progressive release mechanics.

View source documentation

Have developers sign container images locally using personal PGP keys following a self-review checklist, push the images to Artifact Registry, and configure automated vulnerability scanning.

What this option is

This approach relies on individual developers building artifacts on their local workstations, performing self-checks, cryptographically signing images with their personal workstation keys, and relying on Artifact Registry vulnerability scanning.

Why it doesn't meet the requirements

Prevent unilateral changes: Self-review checklists and local developer signing fail completely to prevent unilateral changes. A malicious insider or compromised credential holder can self-sign and deploy unauthorized code.
Verifiable build provenance: Artifacts built on personal developer machines lack non-falsifiable provenance. Local build environments can easily be manipulated, injected with malicious dependencies, or falsify metadata.
Deploy-time policy enforcement: Vulnerability scanning in Artifact Registry checks for known Common Vulnerabilities and Exposures (CVEs) in packages, but it does not act as an admission policy gate validating code reviews or authentic source provenance.

Key limitations

Lacks a centralized, isolated build execution environment required by SLSA Level 2+ specifications.
Personal signing keys stored on developer workstations are vulnerable to theft and misuse.
Does not provide automated deploy-time admission blocking.

This answer would be correct if

The goal was strictly to identify known CVEs in dependencies for local non-production development environments without requiring supply chain integrity or multi-party review enforcement.

View source documentation

Require two-person code reviews in the source control system, execute container builds in a centralized build service that automatically generates signed provenance attestations, and enforce deployment policies using Binary Authorization.

What this solution is

This architecture combines branch protection rules, centralized verifiable build execution, and deploy-time policy admission controllers to establish end-to-end software supply chain security aligned with the Supply-chain Levels for Software Artifacts (SLSA) framework.

How it meets the requirements

Prevent unilateral changes: Enforcing mandatory two-person code reviews in source control ensures that every code change undergoes independent verification before merging. This eliminates the risk of an individual developer acting alone to deploy malicious or unauthorized modifications to production systems.
Verifiable build provenance: Executing builds in a managed, centralized service (such as Cloud Build) isolates the compilation and packaging environment. The build service generates signed, non-falsifiable provenance metadata that explicitly records the source repository URL, commit hash, build entry points, and output artifact hashes.
Deploy-time policy enforcement: Using Binary Authorization introduces an admission control gate on Google Kubernetes Engine (GKE) or Cloud Run. The admission controller verifies cryptographic signatures and attestations against an enterprise policy, ensuring that non-compliant images lacking valid provenance or peer reviews are rejected prior to execution.

Key advantages

Implements the foundational principles of Google's Binary Authorization for Borg (BAB) and SLSA framework.
Mitigates both external supply chain tampering and internal insider threat vectors.
Shifting security checks left into the build phase while maintaining non-bypassable enforcement at the deployment choke point.
Generates an immutable, auditable trail linking production containers back to reviewed source commits.

Why this is optimal

Centralizing build execution and binding it to cryptographic attestations evaluated by Binary Authorization creates a zero-trust build and deployment pipeline that prevents compromised developer workstations or untrusted artifacts from entering production.

View source documentation

Deploy application code using Cloud Run source-to-container continuous deployment triggers directly from developer feature branches, and rely on Cloud Monitoring alerts for unauthorized deployments.

What this option is

This configuration sets up direct continuous deployment triggers where commits to individual developer feature branches automatically build and deploy new container revisions to Cloud Run, utilizing Cloud Monitoring alerts to flag unexpected changes after deployment.

Why it doesn't meet the requirements

Prevent unilateral changes: Deploying directly from unreviewed feature branches allows any individual developer with repository write access to ship code directly to production without peer review.
Verifiable build provenance: While the automated trigger builds the container, deploying straight from unmerged feature branches bypasses standard release tracking, change management approvals, and strict provenance verification.
Deploy-time policy enforcement: Cloud Monitoring alerts provide passive, asynchronous detection after an artifact is already running in production. This fails the requirement for a pre-deployment gate that proactively prevents unauthorized images from executing.

Key limitations

Reactive alerting cannot prevent real-time data exfiltration or system compromise caused by bad deployments.
Violates branch protection best practices and change management standards.
Fails to enforce admission-time policy evaluation.

This answer would be correct if

The team was operating an experimental sandbox environment where velocity is the single priority and security controls like code reviews and admission gates are intentionally omitted.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Enforcing SLSA Provenance with Binary Authorization

An enterprise organization is designing a secure CI/CD pipeline on Google Cloud to align with the Supply-chain Levels for Software Artifacts (SLSA) framework and mitigate insider risk.

The pipeline must satisfy the following security and governance requirements:

Prevent unilateral changes: Ensure that no individual developer acting alone can directly merge unvetted source code into production builds.
Verifiable build provenance: Build container images in an isolated, centralized service that generates tamper-evident provenance metadata linking the artifact to its exact source repository commit and build steps.
Deploy-time policy enforcement: Block the deployment of any container image unless it carries verified attestations confirming mandatory peer reviews and legitimate build provenance.

Which combination of controls and architecture should the DevOps team implement?

Implement feature flags and blue-green traffic shifting in the deployment pipeline, and configure a Change Advisory Board approval gate in the continuous delivery tool.

Have developers sign container images locally using personal PGP keys following a self-review checklist, push the images to Artifact Registry, and configure automated vulnerability scanning.

Deploy application code using Cloud Run source-to-container continuous deployment triggers directly from developer feature branches, and rely on Cloud Monitoring alerts for unauthorized deployments.

Explanations

Implement feature flags and blue-green traffic shifting in the deployment pipeline, and configure a Change Advisory Board approval gate in the continuous delivery tool.

What this option is

Why it doesn't meet the requirements

Prevent unilateral changes: While CAB gates provide operational review, they typically review release tickets rather than performing line-by-line two-person code reviews at the source commit level.
Verifiable build provenance: Feature flags and blue-green deployments manage traffic routing and rollback mechanics; they do not generate cryptographic build provenance tying container images back to source repositories and build parameters.
Deploy-time policy enforcement: CD approval gates check pipeline metadata within the delivery tool, but they do not enforce platform-level admission control (like Binary Authorization) to prevent out-of-band or direct cluster deployments.

Key limitations

Release orchestrator gates can be bypassed if an actor has direct API access to the target deployment cluster.
Traffic shifting mitigates runtime failure blast radius but does not secure the software supply chain against malicious tampering.
Does not satisfy SLSA requirements for isolated build execution and signed provenance.

This answer would be correct if

The team's primary objective was minimizing end-user downtime during application rollouts and controlling feature experimentation through progressive release mechanics.

View source documentation

Have developers sign container images locally using personal PGP keys following a self-review checklist, push the images to Artifact Registry, and configure automated vulnerability scanning.

What this option is

Why it doesn't meet the requirements

Prevent unilateral changes: Self-review checklists and local developer signing fail completely to prevent unilateral changes. A malicious insider or compromised credential holder can self-sign and deploy unauthorized code.
Verifiable build provenance: Artifacts built on personal developer machines lack non-falsifiable provenance. Local build environments can easily be manipulated, injected with malicious dependencies, or falsify metadata.
Deploy-time policy enforcement: Vulnerability scanning in Artifact Registry checks for known Common Vulnerabilities and Exposures (CVEs) in packages, but it does not act as an admission policy gate validating code reviews or authentic source provenance.

Key limitations

Lacks a centralized, isolated build execution environment required by SLSA Level 2+ specifications.
Personal signing keys stored on developer workstations are vulnerable to theft and misuse.
Does not provide automated deploy-time admission blocking.

This answer would be correct if

The goal was strictly to identify known CVEs in dependencies for local non-production development environments without requiring supply chain integrity or multi-party review enforcement.

View source documentation

Require two-person code reviews in the source control system, execute container builds in a centralized build service that automatically generates signed provenance attestations, and enforce deployment policies using Binary Authorization.

What this solution is

How it meets the requirements

Prevent unilateral changes: Enforcing mandatory two-person code reviews in source control ensures that every code change undergoes independent verification before merging. This eliminates the risk of an individual developer acting alone to deploy malicious or unauthorized modifications to production systems.
Verifiable build provenance: Executing builds in a managed, centralized service (such as Cloud Build) isolates the compilation and packaging environment. The build service generates signed, non-falsifiable provenance metadata that explicitly records the source repository URL, commit hash, build entry points, and output artifact hashes.
Deploy-time policy enforcement: Using Binary Authorization introduces an admission control gate on Google Kubernetes Engine (GKE) or Cloud Run. The admission controller verifies cryptographic signatures and attestations against an enterprise policy, ensuring that non-compliant images lacking valid provenance or peer reviews are rejected prior to execution.

Key advantages

Implements the foundational principles of Google's Binary Authorization for Borg (BAB) and SLSA framework.
Mitigates both external supply chain tampering and internal insider threat vectors.
Shifting security checks left into the build phase while maintaining non-bypassable enforcement at the deployment choke point.
Generates an immutable, auditable trail linking production containers back to reviewed source commits.

Why this is optimal

View source documentation

Deploy application code using Cloud Run source-to-container continuous deployment triggers directly from developer feature branches, and rely on Cloud Monitoring alerts for unauthorized deployments.

What this option is

Why it doesn't meet the requirements

Prevent unilateral changes: Deploying directly from unreviewed feature branches allows any individual developer with repository write access to ship code directly to production without peer review.
Verifiable build provenance: While the automated trigger builds the container, deploying straight from unmerged feature branches bypasses standard release tracking, change management approvals, and strict provenance verification.
Deploy-time policy enforcement: Cloud Monitoring alerts provide passive, asynchronous detection after an artifact is already running in production. This fails the requirement for a pre-deployment gate that proactively prevents unauthorized images from executing.

Key limitations

Reactive alerting cannot prevent real-time data exfiltration or system compromise caused by bad deployments.
Violates branch protection best practices and change management standards.
Fails to enforce admission-time policy evaluation.

This answer would be correct if

The team was operating an experimental sandbox environment where velocity is the single priority and security controls like code reviews and admission gates are intentionally omitted.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Enforcing SLSA Provenance with Binary Authorization

Explanations

Implement feature flags and blue-green traffic shifting in the deployment pipeline, and configure a Change Advisory Board approval gate in the continuous delivery tool.

What this option is

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Have developers sign container images locally using personal PGP keys following a self-review checklist, push the images to Artifact Registry, and configure automated vulnerability scanning.

What this option is

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Require two-person code reviews in the source control system, execute container builds in a centralized build service that automatically generates signed provenance attestations, and enforce deployment policies using Binary Authorization.

What this solution is

How it meets the requirements

Key advantages

Why this is optimal

Deploy application code using Cloud Run source-to-container continuous deployment triggers directly from developer feature branches, and rely on Cloud Monitoring alerts for unauthorized deployments.

What this option is

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Cloud Build Binary Authorization Attestation

Artifact Analysis On-Demand Scanning

GKE Cluster Autoscaler Safe-To-Evict Annotation

Automated vs Manual Rollback Criteria

Compute Engine Shared Reservations

Cloud Storage Bucket Lock WORM Retention

Enforcing SLSA Provenance with Binary Authorization

Explanations

Implement feature flags and blue-green traffic shifting in the deployment pipeline, and configure a Change Advisory Board approval gate in the continuous delivery tool.

What this option is

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Have developers sign container images locally using personal PGP keys following a self-review checklist, push the images to Artifact Registry, and configure automated vulnerability scanning.

What this option is

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Require two-person code reviews in the source control system, execute container builds in a centralized build service that automatically generates signed provenance attestations, and enforce deployment policies using Binary Authorization.

What this solution is

How it meets the requirements

Key advantages

Why this is optimal

Deploy application code using Cloud Run source-to-container continuous deployment triggers directly from developer feature branches, and rely on Cloud Monitoring alerts for unauthorized deployments.

What this option is

Why it doesn't meet the requirements

Key limitations

This answer would be correct if

Try 10 interactive questions like this one, free

Related questions

Cloud Build Binary Authorization Attestation

Artifact Analysis On-Demand Scanning

GKE Cluster Autoscaler Safe-To-Evict Annotation

Automated vs Manual Rollback Criteria

Compute Engine Shared Reservations

Cloud Storage Bucket Lock WORM Retention