Securing the Deployment Pipeline & Dev Environments

Table of Contents#

1. Why the Pipeline Itself Is an Attack Surface
2. Artifact Analysis: Scanning What the Pipeline Produces
3. The SLSA Framework: Grading a Pipeline's Own Trustworthiness
4. Binary Authorization: Enforcing What's Allowed to Deploy
5. Software Delivery Shield: The Bundled Picture
6. IAM Policies Based on Environment
7. Cloud Workstations: Secure, Standardized Development Environments
8. Bootstrapping Environments With Required Tooling
9. AI-Assisted Development and Operations
10. A Full Worked Example: Meridian's End-to-End Supply Chain Gate
11. Common Mistakes and Interview Traps
12. Worked Practice Problems
13. Summary and What's Next

Why the Pipeline Itself Is an Attack Surface#

Every prior chapter in this course treated the CI/CD pipeline as the trusted mechanism delivering code safely — this final chapter asks the harder question the exam guide's "securing the deployment pipeline" section (2.4) is really about: what stops the pipeline itself from becoming the attack? A pipeline with unrestricted deploy permissions, no verification of what it's actually shipping, and no record of how an artifact was built is a single high-value target — compromise the pipeline once, and every environment it deploys to is compromised too, often with the legitimate-looking audit trail of an authorized deployment rather than an obvious intrusion.

This is the real-world category of incident behind the software supply-chain attacks that made the SLSA framework and Binary Authorization mainstream priorities industry-wide, not just a GCP-specific concern: a compromised build step, a tampered dependency, or a stolen deploy credential can all produce an artifact that looks completely legitimate to every check this course has built so far, unless the pipeline is specifically hardened against exactly that.

What to notice: each attack path targets a different stage, which is exactly why this chapter's defenses (scanning, provenance, attestation-gated deploy) are layered rather than a single control — a defense that only covers the build step does nothing against a stolen deploy credential bypassing the build entirely.

Artifact Analysis: Scanning What the Pipeline Produces#

Part 3 introduced Artifact Analysis briefly as the mechanism scanning images pushed to Artifact Registry; here's the full picture. Artifact Analysis automatically scans container images for known CVEs across OS packages and, as of recent GA coverage, application-level dependencies too (Python and Node.js package vulnerabilities, not just OS-layer ones) — a real, worth-knowing expansion beyond "just scans the base OS image."

# Query scan results for the exact image Part 3's build produced --
# this is the check a Binary Authorization attestor (next section)
# would gate deployment on
gcloud artifacts docker images list-vulnerabilities \
  us-central1-docker.pkg.dev/meridian-cicd/meridian-images/shipment-api@sha256:abc123... \
  --project=meridian-cicd \
  --format="table(vulnerability.effectiveSeverity, vulnerability.shortDescription)"

The SLSA Framework: Grading a Pipeline's Own Trustworthiness#

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is an industry framework — originally derived from Google's own internal "Binary Authorization for Borg" system, used company-wide for over a decade before being generalized and open-sourced — that grades a build pipeline's own trustworthiness on an increasing scale, rather than grading any single artifact.

Cloud Build provides SLSA Level 3-capable provenance generation out of the box for supported build configurations — isolated, ephemeral build environments (each build gets a clean environment, never reused across builds) plus cryptographically signed provenance attesting to exactly which source commit, which build steps, and which build service produced a given image digest.

💡 The transferable insight: SLSA's escalating levels mirror the same trust-tiering logic as a financial audit's control maturity model — Level 1 is "a record exists," Level 2 is "the record can't be quietly altered after the fact by an ordinary user," Level 3 is "the record can't be forged even by someone with elevated access to the system producing it." Each level closes a progressively more sophisticated threat, not just "more of the same" documentation.

Binary Authorization: Enforcing What's Allowed to Deploy#

SLSA provenance and vulnerability scan results are only useful if something actually enforces them at deploy time — that's Binary Authorization's job. It's a deploy-time admission controller for GKE (and Cloud Run) that blocks any image lacking the required attestations — cryptographically signed statements from a trusted attestor confirming a specific check passed (the vulnerability scan came back clean, the image was built by the expected Cloud Build pipeline, a QA sign-off happened).

# Binary Authorization policy -- requires an attestation from BOTH
# the automated build attestor AND a QA attestor before any image
# can deploy to Meridian's production cluster
name: projects/meridian-prod/policy
globalPolicyEvaluationMode: ENABLE
defaultAdmissionRule:
  evaluationMode: ALWAYS_DENY
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
clusterAdmissionRules:
  us-central1-a.meridian-prod:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
      - projects/meridian-cicd/attestors/vulnerability-scan-passed
      - projects/meridian-cicd/attestors/qa-signoff

What to notice about the defaultAdmissionRule: it's set to ALWAYS_DENY — a deliberate default-deny posture. Only the explicitly listed cluster (meridian-prod, in this case) has a rule permitting deployment at all, and even that requires both attestations. Any image, from any source, targeting any cluster not explicitly covered by a permissive rule is blocked by default.

# The build pipeline itself creates the attestation, immediately
# after the vulnerability scan step from earlier in this chapter
# passes cleanly -- this is what a Cloud Build step actually runs
gcloud container binauthz attestations sign-and-create \
  --project=meridian-cicd \
  --artifact-url="us-central1-docker.pkg.dev/meridian-cicd/meridian-images/shipment-api@sha256:abc123..." \
  --attestor=vulnerability-scan-passed \
  --attestor-project=meridian-cicd \
  --keyversion=projects/meridian-cicd/locations/us-central1/keyRings/binauthz/cryptoKeys/attestor-key/cryptoKeyVersions/1

Software Delivery Shield: The Bundled Picture#

Every control in this chapter so far — Artifact Analysis, SLSA-aligned build provenance, and Binary Authorization — is also sold and documented together under Google's Software Delivery Shield umbrella, a bundled framing of end-to-end supply-chain security across the software lifecycle rather than a single new product to learn. It's worth knowing the name and the framing (the exam guide's "software supply chain security" phrasing points at exactly this), but the individual controls are what actually get configured — there's no separate "Software Delivery Shield" API or console page distinct from turning on the pieces this chapter already covered.

IAM Policies Based on Environment#

This closes a loop the whole course has been building toward: Part 1 established cross-project IAM scoped per target, and this section names the principle explicitly as an exam topic in its own right — IAM grants should differ by environment, not just by role. The same "deployer" identity legitimately needs different permissions in meridian-dev versus meridian-prod, and a security review should be able to answer "what can this pipeline actually do in production" without cross-referencing every environment's grants by hand.

This table is the same shape as Part 1's environment-policy table and Part 4's approval-gate discussion — by this point in the course, the pattern should feel familiar: every chapter's security control tightens in the same direction, from dev toward prod, and none of them exist as a one-off decision made in isolation from the others.

Cloud Workstations: Secure, Standardized Development Environments#

The exam guide's "enabling secure cloud development environments" (1.5) shifts focus from the pipeline to where code is actually written. Cloud Workstations provides browser- or IDE-accessible, fully managed development environments running on ephemeral Compute Engine VMs, with a persistent disk backing only the /home directory — everything else comes from the workstation's container image and is rebuilt fresh on every session start.

What to notice: this ephemeral-image/persistent-home split is the same underlying trade-off as a stateless application container backed by a separate persistent volume — anything a developer needs to survive isn't in the image at all, and anything in the image is reproducible, auditable, and identical for every engineer using it.

Bootstrapping Environments With Required Tooling#

A custom Cloud Workstations image bakes in tools available to every session from the moment it starts, using the same base-image-plus-startup-script convention as most container customization:

# Custom Cloud Workstations image -- extends Google's base VS Code
# image, adding Meridian's pinned toolchain and internal CLI
FROM us-central1-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest

# Pin exact versions -- an unpinned toolchain drifts silently across
# engineers' sessions, the same "one image, many consumers" principle
# from Part 1's Artifact Registry discussion, applied to dev tooling
RUN curl -fsSL https://go.dev/dl/go1.24.0.linux-amd64.tar.gz | tar -C /usr/local -xz
ENV PATH="/usr/local/go/bin:${PATH}"

# Install the internal merictl CLI from Part 1's automation chapter,
# from Meridian's own Artifact Registry generic repository
COPY --from=us-central1-docker.pkg.dev/meridian-cicd/meridian-tools/merictl:latest /merictl /usr/local/bin/merictl

# Startup scripts run in lexicographical order on every session start
COPY startup/configure-gcloud.sh /etc/workstation-startup.d/100-configure-gcloud.sh

🧪 Hands-on checkpoint: set up a scheduled Cloud Build trigger (Part 3's tooling, applied to workstation images now instead of application images) that rebuilds this image whenever Google publishes a new base image update, and confirm the rebuild pipeline re-runs the same Artifact Analysis scan every application image goes through — a stale, unpatched workstation base image is a genuine, easy-to-overlook drift risk otherwise.

AI-Assisted Development and Operations#

The exam guide explicitly names "leveraging AI to assist with development and operations (e.g., Gemini Code Assist, Gemini Cloud Assist, Gemini CLI)" under secure development environments — a real, current reflection of how GCP's own developer tooling has evolved, not a tangential mention. Gemini Code Assist provides in-IDE code completion and chat grounded in a codebase's actual context, available inside Cloud Workstations sessions. Gemini Cloud Assist answers operational questions across GCP's own console and APIs — surfacing a likely root cause for a failing deploy, or summarizing what changed in a project recently. Gemini CLI brings the same assistance to a terminal-first workflow, scriptable alongside the gcloud/kubectl commands this whole course has used directly.

A Full Worked Example: Meridian's End-to-End Supply Chain Gate#

Bringing every chapter of this course together into the one pipeline Meridian actually runs today — this is the complete picture Part 1's tooling-project design was always building toward.

What to notice: this single diagram is every chapter of this course in sequence — a hardened dev environment (this chapter), tested and scanned CI (Part 3), gated and staged CD (Part 4), environment-appropriate configuration (Part 5), and a supply-chain enforcement point that would block the deploy entirely if either attestation were missing (this chapter). No single control here is sufficient alone; together they're the actual answer to "can you build the pipeline that deploys hundreds of releases correctly, every day, without a human approving each one" from Part 1's framing of what PCDE tests.

Common Mistakes and Interview Traps#

Worked Practice Problems#

Problem 1: A security review finds that meridian-staging's GKE cluster has no entry in Binary Authorization's clusterAdmissionRules, while meridian-prod has a strict REQUIRE_ATTESTATION rule. The defaultAdmissionRule is set to ALWAYS_ALLOW. What's the actual security posture of meridian-staging right now, and is this likely intentional?

Answer: Because meridian-staging has no explicit cluster rule, it falls through to the defaultAdmissionRule — which is ALWAYS_ALLOW, meaning any image from any source can deploy there with zero attestation requirement, regardless of how strict meridian-prod's explicit rule is. This is almost certainly unintentional: a permissive default is a common artifact of initial rollout ("get prod locked down first"), and it should be tightened to at least require the vulnerability-scan attestation, with meridian-prod's additional QA sign-off requirement layered on top for that stricter environment specifically.

Problem 2: A team asks whether achieving "SLSA Level 3" means their production application has no supply-chain vulnerabilities. How would you correct this understanding?

Answer: SLSA Level 3 certifies the build platform's resistance to tampering and provenance forgery — it says the pipeline that produced an artifact is hardened and its provenance can be trusted, not that the artifact itself is free of vulnerabilities. A perfectly SLSA Level 3-compliant pipeline can still faithfully build and ship an application with a genuine vulnerable dependency; that's Artifact Analysis's job to catch, a separate and complementary control, not something SLSA level itself guarantees away.

Problem 3: An engineer wants to skip building a custom Cloud Workstations image and instead have every developer manually install their own tools inside the ephemeral session each time it starts. What's the concrete downside of this approach given how Cloud Workstations' storage model works?

Answer: Anything installed outside /home during a session lives only in the ephemeral container image layer for that session — it does not persist to the next session, since only /home is backed by persistent disk. Every developer would have to re-run their manual install steps on every new session start, and different developers would likely end up with inconsistent tool versions, reintroducing exactly the "works on my machine" inconsistency a shared, versioned custom image exists to eliminate.

Summary and What's Next#

This final chapter of the course closed the loop this whole series has been building: Artifact Analysis and SLSA as the trust-and-verification layer over what the pipeline produces, Binary Authorization as the deploy-time enforcement point that actually acts on that trust, environment-scoped IAM as the same "tighten toward prod" principle threaded through every prior chapter, and Cloud Workstations as the hardened, standardized starting point the entire pipeline traces back to. Meridian's end-to-end supply chain gate — from a scanned workstation image through fail-fast CI, dual-attestation-gated CD, and environment-correct configuration — is the complete, real answer to the Friday-afternoon incident that opened Part 1.

This completes GCP DevOps & CI/CD Platform, covering PCDE exam sections 1-2 (bootstrapping an organization and building CI/CD pipelines) in full. The next course in this series, GCP SRE & Observability, picks up PCDE's remaining sections — applying site reliability engineering practices, observability and troubleshooting, and performance/cost optimization — completing the certification's full scope.