🏗️ Securing GCP CI/CD With AI: Artifact Registry and Cloud Build

The most over-privileged identity in a lot of GCP projects isn’t a human — it’s the default Cloud Build service account. Builds run as it, it often carries broad project roles inherited from a quick-start tutorial, and it can push images and deploy them to production. That makes the pipeline the softest target in the whole environment: compromise the build, or trick it into running on untrusted input, and you’ve compromised production. I learned to take this seriously after auditing a project where a pull request from a fork could trigger a build that held deploy rights — a straight line from “anyone on the internet” to “running code in prod.” Securing a pipeline means thinking of it as a supply chain and tightening each link, and AI is good at walking that chain methodically.

Start with the build identity

The first question is always: what can this build actually do, and does it need to? I pull the build service account’s roles and have AI assess them against what the pipeline genuinely requires.

gcloud projects get-iam-policy my-project \
  --flatten="bindings[].members" \
  --filter="bindings.members:serviceAccount:*cloudbuild*" \
  --format="table(bindings.role, bindings.members)"

Prompt: “Here are the roles on our Cloud Build service account. The pipeline needs to: push Docker images to one Artifact Registry repo, and deploy to one Cloud Run service. Identify which of these roles are broader than that requires, and recommend a dedicated service account with only the least-privilege roles scoped to that specific repo and service — not project-wide. List exactly what to grant and what to remove.”

The pattern is almost always the same: a project-level role doing the job of a resource-scoped one. A build that pushes to a single repo needs artifactregistry.writer on that repo, not on the project; a build that deploys one Cloud Run service needs run.developer on that service plus the ability to act as its runtime SA, not editor on everything.

Trigger safety: who can start a build that has these rights

A least-privilege build identity still isn’t safe if untrusted input can trigger it. The two risks are fork PRs triggering a privileged build and untrusted substitutions flowing into shell steps.

Prompt: “Here’s our Cloud Build trigger config and cloudbuild.yaml. Check whether a pull request from a fork could trigger this build, given that the build has push and deploy rights. Also flag any place where a user-controlled substitution variable flows into a shell command (injection risk). Recommend trigger restrictions and safe substitution handling.”

Restricting triggers to trusted branches and never interpolating untrusted substitutions into shell steps closes the two most common pipeline-takeover paths. The model is reliable at spotting the injection pattern because it’s a syntactic one — a ${_USER_INPUT} landing inside a bash -c.

Provenance and scanning: build trustworthy artifacts

Least privilege keeps the pipeline from doing too much; provenance and scanning keep it from shipping bad artifacts. I turn on Artifact Registry vulnerability scanning and, for sensitive deploys, gate admission with Binary Authorization so only signed, attested images run.

Prompt: “We deploy to GKE. Walk me through enabling Artifact Registry vulnerability scanning, producing build provenance from Cloud Build, and using Binary Authorization to admit only images built by our pipeline and signed. Roll Binary Authorization out in dry-run/audit mode first, and define an exception path so an unrelated low-severity CVE doesn’t block an urgent release.”

The dry-run insistence is deliberate. Binary Authorization in enforce mode can block deploys, including the emergency fix you need most, so it goes through audit mode first and ships with a documented break-glass path. Same with failing builds on CVEs — I define the severity threshold and an exception process rather than blanket-blocking, so a critical hotfix isn’t held hostage by an unrelated finding in a base image.

Registry hygiene and secrets

Old, untagged images are both a cost and an attack surface, and secrets smuggled through substitutions or committed files are a recurring audit finding. AI drafts the cleanup policy and checks the secret flow.

gcloud artifacts repositories set-cleanup-policies my-repo \
  --location=us-central1 --policy=cleanup-policy.json

Prompt: “Write an Artifact Registry cleanup policy that deletes untagged images older than 30 days and keeps the most recent 10 tagged release versions. Then review this cloudbuild.yaml: confirm secrets come from Secret Manager via the build’s access rather than substitutions or committed files, and that the build SA has only the specific secret accessor it needs — not broad Secret Manager access.”

The honest division of labor

AI is strong at the structural security work a pipeline needs: spotting an over-broad role, finding an injection-prone substitution, drafting a cleanup policy, and laying out a Binary Authorization rollout. Those are well-defined patterns and the model handles them cleanly. What it can’t know is which permission the pipeline silently depends on three steps deep — so I apply every IAM tightening in a non-production trigger first and confirm a full build-and-deploy still succeeds before touching the real one.

The rules I hold to: least privilege per resource, dry-run for anything that can block a deploy, and a break-glass path for the gates. The reusable prompts live in my prompts library, and the GCP with AI series covers the identity foundations the pipeline rests on, including least-privilege IAM for the service accounts this build acts as. A secured pipeline is one where the most powerful identity in your project finally has only the power it needs.