12.2 Build Provenance and Admission Concepts

Software Supply Chain Security with SLSA & Binary Authorization

Software supply chains have become a primary attack surface for enterprise infrastructure. Adversaries target the continuous integration and delivery lifecycle by injecting malicious dependencies, compromising build pipelines, altering container tags in registries, or bypassing code review controls. Securing this pipeline requires end-to-end cryptographic provenance and strict deploy-time policy enforcement.

In Google Cloud, supply chain security is implemented through two foundational standards and platforms: the Supply chain Levels for Software Artifacts (SLSA) framework and Binary Authorization. The Google Cloud Professional Cloud Developer exam tests your ability to design end-to-end trusted pipelines combining Cloud Build, Container Analysis, Cloud Key Management Service (KMS), and Binary Authorization.

---

The SLSA Framework and Non-Falsifiable Provenance

SLSA (pronounced salsa) is an open-source security framework spearheaded by Google and the OpenSSF that establishes graduated levels of supply chain integrity:

• SLSA Level 1: Documented build process with basic provenance indicating what system built the artifact.
• SLSA Level 2: Hosted build platform (preventing local developer laptop tampering) with service-generated, tamper-evident provenance.
• SLSA Level 3: Isolated and Ephemeral Build Environments. The build platform must guarantee that build steps execute in isolated virtual machines or containers with no cross-build state contamination. Provenance must be non-falsifiable, meaning build steps or malicious scripts inside the build container cannot forge, alter, or inject fraudulent metadata into the build provenance statement. The current SLSA Build track uses levels 1-3. Level 4 was part of an older specification; do not combine historical and current level definitions. Hermeticity and source-review controls remain useful but are not a current Build Level 4.

Non-Falsifiable Build Provenance in Cloud Build

Cloud Build natively generates SLSA Level 3 compliant provenance for supported Artifact Registry outputs when the build is configured to produce and verify provenance. Because provenance generation occurs within Google's control plane rather than inside the user's container execution space, user code cannot fabricate its own provenance.

The provenance statement is formatted as an in-toto attestation (JSON statement with a signed envelope) containing:

• Immutable digest (SHA256) of the resulting container image.
• Git repository source URI, branch, and exact commit SHA.
• Build configuration file location and step arguments.
• Entrypoint builders and environment variables.
• Google Cloud signature certifying authenticity.

## Inspecting SLSA build provenance for an image in Artifact Registry
gcloud artifacts docker images describe \
    us-central1-docker.pkg.dev/my-project/apps/order-service@sha256:7a8b9c... \
    --show-provenance

---

Configuring and Checking Provenance

steps:
- name: gcr.io/cloud-builders/docker
  args: [build, -t, 'us-central1-docker.pkg.dev/$PROJECT_ID/apps/order-service:$BUILD_ID', .]
images:
- 'us-central1-docker.pkg.dev/$PROJECT_ID/apps/order-service:$BUILD_ID'
options:
  requestedVerifyOption: VERIFIED

Cloud Build's images output plus verified provenance configuration matters: an arbitrary explicit docker push is not equivalent. Inspect provenance and the resulting digest after this build completes. A separate promotion step can then evaluate scan results, create the required attestation, and deploy that exact digest. Provenance proves origin/build history under a trust policy; it does not prove the application is bug-free or that tests covered every requirement.

Binary Authorization: Deploy-Time Gatekeeping

While SLSA and vulnerability scanners operate during the CI phase, Binary Authorization acts as the gatekeeper at the moment of deployment. It is an admission control security service integrated natively into Google Kubernetes Engine (GKE) and Cloud Run.

How Binary Authorization Works

When a developer or CI pipeline attempts to create a GKE Pod or deploy a Cloud Run service:

1. The deployment request containing the container image URI is submitted to the platform API server.
2. The platform's internal Admission Controller Webhook intercepts the request before any container is scheduled or instantiated.
3. The admission webhook forwards the image digest to the Binary Authorization evaluation engine.
4. Binary Authorization checks the container image against the project's Binary Authorization Policy.
5. If the image satisfies all required policy rules (e.g., possesses valid cryptographic attestations), the request is admitted. If non-compliant, the deployment is rejected with an HTTP 403 Forbidden error.

[ Developer / CI/CD ]
         |
         v (1. Deploy Manifest: image@sha256:...)
[ GKE / Cloud Run API Server ]
         |
         v (2. Intercept via Admission Controller)
[ Binary Authorization Engine ] <---> (3. Verify Attestation Signatures against KMS Key)
         |
   +-----+-----+
   |           |
(Admitted)  (Rejected: 403 Forbidden)
   |           |
   v           v
[ Pod Runs ] [ Deployment Blocked + Audit Log Written ]

Verify the Artifact Subject

Compare the image digest in the deployment with the subject digest in the signed provenance. Then check the trusted builder identity and expected source repository/commit under the verification policy. A valid signature over a different artifact, or a build from an unapproved repository, is not evidence for the image being released. Keep build provenance distinct from a later vulnerability-scan or QA attestation, because each asserts a different fact.

Official references checked October 18, 2026: Google Cloud 1.