GCP Cloud Build is the rare CI service that ships strong supply chain primitives in the box. SLSA Level 3 provenance is generated by default. Workload Identity Federation eliminates long-lived credentials. Binary Authorization enforces signature requirements at deploy time. The platform is genuinely defensible.
The catch is that most GCP shops have not turned the primitives on. I have audited about thirty Cloud Build deployments in the last twelve months, and roughly two thirds of them were running the same pre-2024 patterns: service account key files in build configurations, manual provenance generation, no Binary Authorization. The defensive posture you can have on Cloud Build in 2026 is materially better than what you can have on most other CI services, but only if you actually configure it.
Why is Cloud Build the easiest of the three big clouds to defend, when configured?
Because Google ships the primitives that AWS and Azure customers have to bolt on. SLSA Level 3 provenance is generated automatically for any Cloud Build run that uses the v2 build configuration, and the provenance is signed by Google's KMS-backed signing service. The customer does not maintain the signing key, the build environment, or the provenance generation pipeline. Google does.
That said, the default configuration is not safe. The default Cloud Build service account has wide permissions. The default trigger configuration accepts builds from any branch on the connected repository. The default artifact registry policy does not require Binary Authorization. The defender's job is to constrain those defaults, not to add new primitives.
The threat model in 2026 has shifted toward supply chain attacks that target the trigger configuration rather than the build itself. An attacker who modifies a Cloud Build trigger to point at a malicious branch, or who adds a new trigger that runs malicious code under the project's deploy permissions, has compromised the entire build path without ever touching a build step. The defence is to lock down trigger management as tightly as you would lock down IAM.
How do I get rid of service account key files in Cloud Build?
Use Workload Identity Federation for every external system the build interacts with, and delete every JSON key file from the build configuration. Workload Identity Federation issues short-lived OIDC tokens that the build exchanges for Google Cloud credentials at run time, and the tokens cannot be reused outside the build context.
The migration is one-time and not very expensive. You configure a workload identity pool, bind it to the Cloud Build service account, and update the build steps to use the federation flow. The build steps no longer reference any key file, and the IAM policy on the source key file can be deleted. The break-glass procedure for the migration is documented in Google's own docs and works as advertised.
The harder change is the cross-cloud federation case. If your Cloud Build pipeline pushes to AWS or Azure, you need federation in both directions. AWS supports OIDC federation from Google's identity provider, and Azure supports it via the federated identity credential feature. Both work, both require configuration on the destination side, and both eliminate the long-lived key file that would otherwise be the highest-value secret in the build.
What does provenance enforcement look like in Cloud Build in 2026?
Use the v2 build configuration with requestedVerifyOption: VERIFIED, push every artifact to Artifact Registry with the Binary Authorization attestor configured, and require a Binary Authorization policy on every GKE cluster, Cloud Run service, and Cloud Functions deployment that consumes the artifacts.
The VERIFIED option requires Cloud Build to generate SLSA Level 3 provenance and attach it to the artifact in Artifact Registry. The provenance is signed by Google's KMS-backed signer, and the signature is verifiable by anyone with the signer's public key. The attestation is the artifact's passport: without it, the artifact cannot be deployed under a Binary Authorization policy that requires verification.
The Binary Authorization attestor is the enforcement point. An attestor verifies signatures on behalf of a Binary Authorization policy, and the policy refuses to admit any image that does not have a valid attestation. Configuring the attestor with the Cloud Build signer's public key, and then configuring every relevant deploy target with a policy that requires the attestor, gives you an end-to-end verified supply chain that breaks if anyone tries to deploy an unsigned artifact.
The gap most teams miss is the development cluster. Many shops configure Binary Authorization on production but leave it off on development clusters, which means an attacker can push an unsigned image to a development cluster, exfiltrate from there, and use the development cluster's network access to reach production. Configure Binary Authorization on every cluster, including development, with the policy adjusted for the trust level rather than disabled.
How do I keep Cloud Build triggers from becoming the attack path?
Lock down trigger creation and modification with IAM, require that every trigger reference a specific branch by exact match, and enable the new trigger-level approval requirement for any trigger that runs under a service account with production permissions.
The trigger creation permission is cloudbuild.builds.create plus cloudbuild.builds.update, and most projects grant it to the entire developer team. That is too wide. The fix is to grant it to a small set of platform team members, and to require pull-request review on the Terraform or config-as-code that defines the triggers. Cloud Build does not natively enforce this, but the IAM permission is the chokepoint.
The branch-exact-match requirement is straightforward — use the regex anchor on the branch field, not a wildcard. The trigger-level approval is newer and worth using. It requires that a designated approver explicitly approve the build before it runs, with the approver's identity recorded in Cloud Audit Logs. For triggers that deploy to production, the approval step is the last line of defence against a malicious trigger configuration.
What about Cloud Build pools and private network egress?
Use private pools with explicit VPC peering and a scanned proxy for outbound traffic, never the default public pool for any production-impacting build. The private pool runs in a VPC the customer controls, with the same network controls as any other GCE resource: firewall rules, VPC Service Controls, and audit logs.
The default pool is convenient and inappropriate for production. It runs in a Google-managed network that the customer cannot inspect or control. Builds that need to fetch dependencies from a private package registry, communicate with an internal artifact store, or call an internal API cannot do so safely from the default pool. The private pool fixes all three.
VPC Service Controls is the additional layer that most security-mature GCP shops use. A perimeter that includes the build pool, the artifact registry, and the deploy targets blocks data exfiltration to outside the perimeter even if a build is compromised. Configuring the perimeter is non-trivial, but the runtime protection is real.
How Safeguard Helps
Safeguard ingests Cloud Build configuration, trigger definitions, and Artifact Registry attestation state, and produces a continuous posture signal that maps to the controls above. The signal flags triggers that lack approval requirements, builds that emit no SLSA provenance, and deploy targets that admit images without attestation.
Griffin AI generates Workload Identity Federation pool configurations, Binary Authorization policies, and private pool networking from an existing Cloud Build deployment, then opens merge requests against the customer's IaC repo to roll the changes out. The MR-driven workflow is what makes the rollout tractable in projects with dozens or hundreds of triggers.
Safeguard's SBOM module verifies the SLSA provenance on every Cloud Build artifact and attaches a layered SBOM that survives the deploy. The TPRM module tracks the trust state of every external source repository connected to Cloud Build and every public package the build consumes, and the policy gate module integrates with Cloud Build's approval feature so a build approval can be wired to a Safeguard policy decision rather than a hand-coded check.
For multi-project GCP organizations, Safeguard rolls up Cloud Build posture across all projects, so the security team has a single view of which projects are out of compliance and a single workflow for remediation. The reachability scoring on Cloud Build artifacts cuts noise dramatically — vulnerabilities in build-time-only dependencies are deprioritized automatically, freeing engineering time for issues that actually affect deployed workloads.