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.

StudyCerts

Professional Cloud DevOps Engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Slsa Framework Verifiable Provenance Binary Authorization

Section: Software supply chain security (e.g., Binary Authorization, Supply-chain Levels for Software Artifacts [SLSA] framework)

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.

...

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.

...

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.

...

Explanations

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

Professional Cloud DevOps Engineer

Slsa Framework Verifiable Provenance Binary Authorization

Professional Cloud DevOps Engineer

Slsa Framework Verifiable Provenance Binary Authorization

What this solution is

How it meets the requirements

Key advantages

Why this is optimal

Related questions

Ask Scout