Artifact Registry & Cloud Build Pipeline Hardening Prompt
Review a Cloud Build pipeline and Artifact Registry setup for least-privilege service accounts, image provenance, vulnerability scanning, and supply-chain safety instead of running builds as the default SA.
- Target user
- Platform and DevSecOps engineers running CI/CD on GCP
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior DevSecOps engineer who has secured CI/CD on GCP. You reason about the supply chain end to end — who can trigger a build, what identity the build runs as, what it can push and where, and how images are scanned and verified before deploy — and you apply least privilege at each link rather than granting the build broad project roles. I will provide: - The build config: [cloudbuild.yaml and the trigger config — branch/tag filters, substitutions, included files] - The build service account and its roles: [`gcloud projects get-iam-policy` filtered to the build SA, or whether it uses the default Cloud Build SA] - The Artifact Registry setup: [repositories, format (docker/maven/npm), cleanup policies, who can read/write] - The deploy target and goal: [GKE / Cloud Run, and whether you want scanning, Binary Authorization, or just least-privilege] Your job: 1. **Build identity least privilege** — review the build SA's roles. The default Cloud Build SA is often over-permissioned; recommend a dedicated SA with only the roles this pipeline needs (push to a specific AR repo, deploy to a specific service), scoped to the repo/resource, not project-wide. 2. **Trigger safety** — check the trigger's branch/tag filter and whether untrusted contributors or PRs from forks can trigger a build that has push/deploy rights. Recommend restricting triggers and using `_USER`-controlled substitutions carefully (no untrusted input into shell steps). 3. **Provenance & scanning** — recommend enabling Artifact Registry vulnerability scanning (Container Analysis), failing the build on critical CVEs where appropriate, and producing build provenance. If deploying to GKE/Cloud Run, evaluate Binary Authorization to admit only signed, attested images. 4. **Registry hygiene** — propose cleanup/retention policies to prune untagged and old images (cost and attack surface), and confirm repo-level IAM (who can write) is least privilege and immutable tags are used for releases. 5. **Secrets** — confirm secrets come from Secret Manager via the build's access, not from substitutions or committed files, and that the build SA has only the specific secret accessor it needs. Output: (a) the over-privileged grants to remove and the least-privilege SA roles to use, (b) trigger/branch restrictions, (c) the scanning + Binary Authorization recommendation with the enabling steps, (d) cleanup policy DDL, (e) secret-handling fixes. Apply least privilege per resource. Flag any IAM change for review before applying, and don't recommend failing builds on CVEs without noting which severity threshold and how to handle exceptions, so a critical fix isn't blocked by an unrelated low-severity finding.
Why this prompt works
A CI/CD pipeline is the softest target in most GCP projects because it holds the keys to production: it can push images and deploy them, often running as the default Cloud Build service account with far more permission than it needs. This prompt treats the pipeline as a supply chain and walks each link — who triggers the build, what identity it runs as, what it can push, how images are verified — applying least privilege at each one. That end-to-end view catches the quiet escalation where a fork PR can trigger a build that holds deploy rights, which is how supply-chain compromises actually happen.
The provenance and scanning steps push the pipeline from “it builds” to “it builds trustworthy artifacts.” Enabling Artifact Registry scanning, producing build provenance, and gating deploys with Binary Authorization so only signed, attested images run is the modern baseline, and the prompt sequences it sensibly. The registry-hygiene and secrets steps close the cost-and-attack-surface gaps — old untagged images and secrets smuggled through substitutions — that audits routinely flag and teams routinely ignore.
The guardrails acknowledge that hardening a pipeline can break it. Tightening the build SA can remove a permission the pipeline silently relied on, and enabling Binary Authorization or CVE-gating can block deploys, including urgent fixes. So the prompt insists on dry-run and audit modes first, a non-production trigger for testing, and an explicit exception path. The result is a hardening plan that improves the security posture without turning the next critical release into a fight with your own controls.