Google Cloud Build is one of the few CI/CD platforms with native support for SLSA provenance generation. That matters because provenance -- a verifiable record of how an artifact was built -- is the foundation of supply chain security. But most teams using Cloud Build never enable provenance, never integrate Binary Authorization, and never think about the security properties of their build pipeline.
This post covers how to use Cloud Build's security features to build a genuine supply chain integrity system, not just a faster way to push containers.
The Supply Chain Threat Model for Cloud Build
Before configuring anything, understand what you are defending against.
Compromised source code. An attacker gains access to your repository and injects malicious code. Cloud Build will faithfully build and deploy it. Defenses: code review, branch protection, signed commits.
Compromised dependencies. Your build pulls a package that has been tampered with upstream. Your code is clean, but the artifact is not. Defenses: dependency pinning, private mirrors, SBOM analysis.
Compromised build environment. An attacker modifies your Cloud Build configuration to inject steps, exfiltrate secrets, or alter the output artifact. Defenses: build config review, immutable build steps, provenance verification.
Artifact tampering. An attacker modifies an artifact after it is built but before it is deployed. Defenses: image signing, attestation, Binary Authorization.
A solid Cloud Build security strategy addresses all four vectors.
Enabling SLSA Provenance
Cloud Build can automatically generate SLSA Build Level 3 provenance for container images. This provenance record includes the source repository, commit hash, build configuration, builder identity, and build parameters.
Enable provenance generation. In your cloudbuild.yaml, set requestedVerifyOption: VERIFIED on your Docker build steps. Cloud Build will generate signed provenance and attach it to the image in Artifact Registry.
Verify provenance before deployment. Use the gcloud artifacts docker images describe command to inspect provenance for any image. Integrate provenance verification into your deployment pipeline so that images without valid provenance are rejected.
Understand what provenance proves. SLSA provenance tells you that a specific image was built from a specific source commit using a specific build configuration on a specific builder. It does not tell you that the source code is free of vulnerabilities or that the dependencies are trustworthy. It is one layer of a multi-layer defense.
Securing the Build Configuration
Your cloudbuild.yaml file defines what happens during a build. It is as security-sensitive as your application code.
Store build configs in version control. Never create builds through the Cloud Build UI with inline configurations. Keep all build configurations in your repository, subject to code review and version control.
Use verified builder images. Every step in Cloud Build runs inside a container. Pin those containers to specific digests, not tags. The official Cloud Build builders (gcr.io/cloud-builders/docker, etc.) are maintained by Google, but you should still pin them.
steps:
- name: 'gcr.io/cloud-builders/docker@sha256:abc123...'
args: ['build', '-t', '$_IMAGE_NAME', '.']
Avoid shell steps when possible. The gcr.io/cloud-builders/gcloud builder with inline shell commands is convenient but harder to audit. Prefer purpose-built builder images with explicit arguments.
Review build configs in pull requests. Treat changes to cloudbuild.yaml with the same scrutiny as changes to your Terraform configurations. A malicious build config change can exfiltrate every secret your pipeline has access to.
Secret Management in Cloud Build
Cloud Build has built-in integration with Secret Manager for handling sensitive values.
Use Secret Manager references. Instead of passing secrets as substitution variables or environment variables, reference them from Secret Manager directly in your build config.
availableSecrets:
secretManager:
- versionName: projects/my-project/secrets/my-api-key/versions/latest
env: 'API_KEY'
Scope secret access. The Cloud Build service account needs secretmanager.secretAccessor on each secret it accesses. Grant this on individual secrets, not at the project level.
Never log secrets. Audit your build steps to ensure they do not echo or print environment variables. A single printenv in a debug step can expose every secret in your build.
Rotate secrets regularly. Even with Secret Manager, rotate credentials on a schedule. Cloud Build makes this easier because you reference secret versions -- updating the secret does not require changing the build config.
Build Service Account Hardening
The Cloud Build service account is the identity your builds run as. Its permissions define the blast radius of a compromised build.
Use a custom service account. Cloud Build's default service account has broad permissions including Cloud Build Editor, which lets it modify other builds. Create a custom service account with only the permissions your build needs.
Minimize IAM roles. A typical build needs Artifact Registry Writer (to push images), Secret Manager Secret Accessor (for specific secrets), and Logs Writer (for build logging). It does not need Compute Admin, Storage Admin, or most other roles.
Use different service accounts for different pipelines. Your frontend build and your infrastructure deployment should use different service accounts with different permissions. A compromised frontend build should not be able to modify infrastructure.
Network Security for Builds
Cloud Build runs in a Google-managed environment by default. For sensitive workloads, you can run builds in a private pool with VPC connectivity.
Use private pools for sensitive builds. Private pools run inside your VPC, giving you control over network egress. This prevents a compromised build step from communicating with external command-and-control infrastructure.
Restrict egress with firewall rules. Configure firewall rules on your private pool's VPC to allow only necessary outbound connections -- Artifact Registry, Secret Manager, and your dependency mirrors. Block everything else.
Use VPC Service Controls. Place your private pool, Artifact Registry, and Secret Manager inside a VPC Service Controls perimeter. This prevents data exfiltration even if an attacker gains authenticated access.
Integrating with Binary Authorization
Binary Authorization enforces deployment policies on GKE. Cloud Build can automatically create attestations that Binary Authorization checks.
Set up attestors for build verification. Create a Binary Authorization attestor that corresponds to your Cloud Build pipeline. After a successful build, Cloud Build creates an attestation signed with a Cloud KMS key.
Require attestations for deployment. Configure your GKE clusters' Binary Authorization policy to require attestations from your build attestor. Only images that were built by your approved pipeline can be deployed.
Add security scan attestors. Create a separate attestor for vulnerability scanning. After scanning an image, your pipeline creates an additional attestation. Binary Authorization can require both build and scan attestations, ensuring that only scanned images reach production.
Monitoring and Audit
Visibility into build activity is essential for detecting compromises.
Enable Cloud Audit Logs for Cloud Build. This captures every API call to Cloud Build, including build creation, modification, and cancellation.
Monitor build patterns. Set up alerts for builds triggered outside normal hours, builds from unexpected branches, builds with modified configurations, and builds that take significantly longer than usual.
Track build artifact hashes. Log the digest of every artifact produced by your builds. If an artifact's digest does not match what the build produced, something has been tampered with.
Export logs for analysis. Send Cloud Build logs to BigQuery for long-term retention and analysis. Build logs can contain valuable forensic information during an incident investigation.
Dependency Management
Cloud Build pulls dependencies during the build. Controlling what enters the build environment is critical.
Use Artifact Registry remote repositories. Configure remote repositories as proxies for Docker Hub, npm, PyPI, and Maven Central. All dependency pulls go through Artifact Registry, giving you visibility and caching.
Pin all dependencies. Use lock files (package-lock.json, go.sum, requirements.txt with hashes) and verify them during the build. Do not rely on version ranges that could resolve to a compromised newer version.
Scan dependencies before building. Add a build step that runs a dependency audit before the main build. If the audit finds known-vulnerable dependencies, fail the build.
How Safeguard.sh Helps
Safeguard.sh integrates with Google Cloud Build to provide comprehensive supply chain security that builds on GCP's native capabilities. It automatically generates SBOMs during builds, correlates SLSA provenance with vulnerability data, and provides continuous monitoring of all artifacts in your Artifact Registry.
The platform adds context that Cloud Build's native tools do not provide -- which vulnerabilities are actually exploitable, which affected images are running in production, and what your remediation priority should be. It turns Cloud Build from a build system that happens to produce provenance into a full supply chain security platform.