Securing Cloud Build Supply Chains with SLSA Level 3 Attestations

Enhancing Cloud Build Supply Chain Security with SLSA Attestations

The integrity of your software supply chain is paramount. Compromised build processes or untrusted artifacts introduce significant risk, potentially leading to widespread system vulnerabilities. To mitigate this, engineering teams are adopting frameworks like Supply-chain Levels for Software Artifacts (SLSA). runred.ai connects application source code with live GCP infrastructure context to discover vulnerabilities with contextual severity scoring, automatically generate integration tests, and generate immutable NIS2, SOC2 Type II, and ISO 27001 audit evidence written to Cloud Logging. Implementing robust Cloud Build supply chain security with SLSA attestations provides a verifiable chain of custody, ensuring that deployed artifacts originate from trusted sources and have not been tampered with. SLSA Level 3 mandates that your build process is hermetic and generates non-falsifiable provenance. This means the build environment must be isolated, ephemeral, and produce a cryptographically signed record of how an artifact was built, including its source code, dependencies, and build steps. For organizations operating on Google Cloud Platform, Cloud Build is a natural fit for achieving these requirements, offering isolated build environments and native integration with Artifact Registry and Binary Authorization.

Implementing SLSA Level 3 Attestations in Cloud Build

Achieving SLSA Level 3 with Cloud Build involves specific configurations within your `cloudbuild.yaml` to generate and store attestations. Cloud Build’s ephemeral worker VMs inherently support the isolation required for hermetic builds, ensuring that each build starts from a clean state. The critical step is to integrate the attestation generation directly into your build pipeline. After your application image is built and pushed to Artifact Registry, your `cloudbuild.yaml` should include steps to generate an in-toto attestation. This attestation records the build process and is signed by the Cloud Build service account. For example, to generate an attestation for a container image: steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image:$COMMIT_SHA', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['push', 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image:$COMMIT_SHA'] - name: 'gcr.io/google.com/cloudsdk/cloud-sdk' entrypoint: 'bash' args: - '-c' - | gcloud artifacts signatures attest \ us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image:$COMMIT_SHA \ --key-version=projects/$PROJECT_ID/locations/us-central1/keyRings/my-keyring/cryptoKeys/my-key/cryptoKeyVersions/1 \ --attestor=projects/$PROJECT_ID/attestors/my-attestor \ --artifact-url=us-central1-docker.pkg.dev/$PROJECT_ID/my-repo/my-image:$COMMIT_SHA \ --payload-path=/workspace/provenance.json \ --builder-id=cloudbuild.googleapis.com/$PROJECT_NUMBER This example uses `gcloud artifacts signatures attest` to create a signed attestation, referencing a KMS key for signing and an existing Binary Authorization attestor. The `provenance.json` payload would contain the SLSA-compliant build details. For Software Bill of Materials (SBOM) attestations, `gcloud artifacts sbom attest` can be used similarly.

Enforcing Provenance with Binary Authorization

Generating attestations is only half the solution; enforcing their presence and validity is crucial. Google Cloud's Binary Authorization service allows your team to define policies that prevent the deployment of container images unless they have been signed by trusted attestors. By integrating Cloud Build-generated SLSA attestations with Binary Authorization, you establish a robust gate that ensures only authorized and verified artifacts reach your production environments. A Binary Authorization policy can be configured to require attestations from your Cloud Build service account, specifically for images pushed to your Artifact Registry. For instance, a policy might demand that an image deployed to a GKE cluster must have an attestation signed by the KMS key managed by your Cloud Build pipeline. If an image lacks the required attestation or if the attestation's signature cannot be verified against the configured public key, Binary Authorization will block its deployment. This enforcement mechanism is critical for preventing supply chain attacks, such as the deployment of a malicious image that bypassed your CI/CD pipeline or was tampered with post-build. Your team can update Binary Authorization policies using `gcloud container binauthz policies update` to specify required attestors and their associated KMS public keys.

Automating Attestation Verification and Compliance

Manually verifying every attestation across a complex application landscape is impractical and error-prone. This is where automated AppSec frameworks become essential. runred.ai continuously monitors your GCP environment, including Artifact Registry and Cloud Build logs, to verify that SLSA attestations are consistently generated and correctly signed. Beyond simple presence, runred.ai can assess the content of these attestations against your defined SLSA policies, flagging any deviations. For example, if an attestation claims a hermetic build but the underlying Cloud Build configuration allows external network access, runred.ai identifies this discrepancy. This automated verification reduces the operational burden on your security and DevOps teams, ensuring ongoing compliance with standards like NIS2 and SOC2 Type II. All verification results and audit trails are immutably written to Cloud Logging, providing a comprehensive, tamper-proof record for auditors without manual effort. This proactive approach ensures that your Cloud Build supply chain security SLSA attestations are not just present, but also effective in mitigating real-world risks.