{"id":611,"date":"2026-04-14T18:00:45","date_gmt":"2026-04-14T18:00:45","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-software-supply-chain-security-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/"},"modified":"2026-04-14T18:00:45","modified_gmt":"2026-04-14T18:00:45","slug":"google-cloud-software-supply-chain-security-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-software-supply-chain-security-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/","title":{"rendered":"Google Cloud Software supply chain security Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application development"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Application development<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What this service is<\/h3>\n\n\n\n<p>In Google Cloud, <strong>Software supply chain security<\/strong> is an <strong>end-to-end approach and set of Google Cloud services<\/strong> used to secure how software is sourced, built, stored, verified, and deployed\u2014especially for containerized workloads and Kubernetes-based application development.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph simple explanation<\/h3>\n\n\n\n<p>Software supply chain security helps you ensure that what you deploy to production is exactly what you intended to build\u2014free from tampering, signed\/verified, traceable back to source, and continuously checked for known vulnerabilities.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph technical explanation<\/h3>\n\n\n\n<p>Practically, Software supply chain security on Google Cloud is implemented by combining services such as <strong>Cloud Build<\/strong> (trusted builds and provenance), <strong>Artifact Registry<\/strong> (artifact storage and scanning), <strong>Container Analysis<\/strong> (metadata and vulnerability findings), <strong>Binary Authorization<\/strong> (policy-based deployment enforcement for signed\/attested artifacts), and <strong>Cloud KMS<\/strong> (key management for signing). In production, it often integrates with <strong>GKE<\/strong>, <strong>Cloud Deploy<\/strong>, <strong>IAM<\/strong>, <strong>Cloud Logging<\/strong>, and optional controls like <strong>Security Command Center<\/strong> and <strong>Assured OSS<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What problem it solves<\/h3>\n\n\n\n<p>Modern applications depend on thousands of upstream dependencies, CI\/CD systems, container images, and deployment automations. Attackers increasingly target these paths (dependency confusion, poisoned packages, compromised CI credentials, image tampering). Software supply chain security reduces the risk by:\n&#8211; enforcing <strong>trusted build and artifact integrity<\/strong>\n&#8211; requiring <strong>attestations\/signatures<\/strong> before deploy\n&#8211; improving <strong>traceability<\/strong> (who built what, from which source, when)\n&#8211; adding <strong>continuous vulnerability visibility<\/strong> for artifacts<\/p>\n\n\n\n<blockquote>\n<p>Naming clarification (important): In Google Cloud documentation, <strong>\u201cSoftware supply chain security\u201d is commonly presented as a solution area<\/strong> spanning multiple products rather than a single standalone API\/service. If Google Cloud introduces a unified product page or bundles features under a specific SKU over time, <strong>verify the latest official docs<\/strong> for any naming or packaging changes.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Software supply chain security?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>The purpose of Software supply chain security in Google Cloud is to help organizations <strong>protect the software delivery lifecycle<\/strong>\u2014from code and dependencies to build outputs and runtime deployment\u2014by applying <strong>policy, provenance, vulnerability insight, and cryptographic verification<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Core capabilities typically include:\n&#8211; <strong>Trusted build execution<\/strong> and controlled build environments\n&#8211; <strong>Artifact storage<\/strong> with access controls and auditability\n&#8211; <strong>Vulnerability detection<\/strong> for container images (and sometimes language packages, depending on tooling)\n&#8211; <strong>Provenance\/metadata<\/strong> about builds and artifacts\n&#8211; <strong>Policy enforcement<\/strong> at deploy time (block untrusted or non-compliant artifacts)\n&#8211; <strong>Key management<\/strong> for signing\/verification and rotation\n&#8211; <strong>Audit logging<\/strong> for actions across the pipeline<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (common Google Cloud building blocks)<\/h3>\n\n\n\n<p>Because Software supply chain security is a solution area, the \u201ccomponents\u201d are usually these services:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Component<\/th>\n<th>What it contributes to supply chain security<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/build\/docs\">Cloud Build<\/a><\/td>\n<td>CI builds in Google-managed infrastructure; integrates with IAM; can produce build metadata\/provenance (verify current provenance\/SLSA features in docs).<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/artifact-registry\/docs\">Artifact Registry<\/a><\/td>\n<td>Stores container images and language packages; supports IAM controls; integrates with vulnerability scanning (verify exact scanning options by repo type\/region).<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/container-analysis\/docs\">Container Analysis<\/a><\/td>\n<td>Stores and serves metadata about artifacts (vulnerabilities and other occurrences). Often the backend for container scanning\/metadata.<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/binary-authorization\/docs\">Binary Authorization<\/a><\/td>\n<td>Enforces deploy-time policies for container images on supported platforms (commonly GKE). Uses attestations (signed statements) to allow\/deny deployment.<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/kms\/docs\">Cloud KMS<\/a><\/td>\n<td>Manages cryptographic keys used to sign attestations and verify signatures; supports rotation and auditing.<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/kubernetes-engine\/docs\">GKE (Google Kubernetes Engine)<\/a><\/td>\n<td>Primary deployment target where enforce-at-deploy supply chain policy is commonly implemented.<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/deploy\/docs\">Cloud Deploy<\/a> (optional)<\/td>\n<td>Progressive delivery and approvals; can complement supply chain controls by standardizing release flows.<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/assured-open-source-software\">Assured OSS<\/a> (optional)<\/td>\n<td>Curated and hardened open-source packages (availability and scope can vary; verify in docs).<\/td>\n<\/tr>\n<tr>\n<td><a href=\"https:\/\/cloud.google.com\/security-command-center\/docs\">Security Command Center<\/a> (optional)<\/td>\n<td>Aggregates security findings across the environment; can complement supply chain security operations.<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<p>Software supply chain security here is best understood as a <strong>reference architecture \/ set of managed services<\/strong> rather than a single service endpoint. Each component is a managed Google Cloud service with its own APIs, billing, and IAM model.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (regional\/global\/project-scoped)<\/h3>\n\n\n\n<p>Because it is multi-service, scope depends on the component:\n&#8211; <strong>Cloud Build<\/strong>: project-scoped; builds run in Google-managed infrastructure; regional behavior varies by configuration (verify current regionality in docs).\n&#8211; <strong>Artifact Registry<\/strong>: repository is <strong>regional or multi-regional<\/strong> depending on configuration (verify available locations).\n&#8211; <strong>Binary Authorization<\/strong>: policy is typically <strong>project-scoped<\/strong> and enforced by supported runtimes (commonly GKE clusters configured to enforce the policy).\n&#8211; <strong>Cloud KMS<\/strong>: keys are <strong>location-scoped<\/strong> (regional or multi-regional).\n&#8211; <strong>GKE<\/strong>: cluster is <strong>zonal or regional<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>In Google Cloud \u201cApplication development\u201d, Software supply chain security fits as the <strong>security layer across CI\/CD<\/strong>:\n&#8211; <strong>Build<\/strong>: Cloud Build runs builds with controlled identity and logs\n&#8211; <strong>Store<\/strong>: Artifact Registry is the controlled artifact repository\n&#8211; <strong>Analyze<\/strong>: Container Analysis provides vulnerability and metadata visibility\n&#8211; <strong>Enforce<\/strong>: Binary Authorization denies deploys that fail policy\n&#8211; <strong>Operate<\/strong>: Cloud Logging\/Monitoring, IAM, SCC support governance and incident response<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Software supply chain security?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reduce the likelihood of high-impact breaches caused by compromised dependencies or CI\/CD pipelines.<\/li>\n<li>Improve customer trust by demonstrating controls like signed artifacts, auditable builds, and vulnerability management.<\/li>\n<li>Shorten incident response time with better traceability: \u201cWhich build produced this artifact and who triggered it?\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce <strong>immutable deploys<\/strong> by using image digests and attestation checks.<\/li>\n<li>Build a <strong>repeatable chain of custody<\/strong> from source to runtime.<\/li>\n<li>Centralize artifacts and reduce sprawl across developer laptops and ad-hoc registries.<\/li>\n<li>Integrate identity (IAM), encryption (KMS), and logging into the delivery process.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize CI\/CD patterns across teams (especially platform teams).<\/li>\n<li>Improve audit readiness: access logs, build logs, artifact histories, and policy decisions are visible and reviewable.<\/li>\n<li>Separate duties: builders sign, deployers verify, clusters enforce.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Support compliance evidence for secure SDLC controls (exact mapping depends on your compliance framework and implementation).<\/li>\n<li>Enforce \u201conly verified images can run in production.\u201d<\/li>\n<li>Reduce exposure to known CVEs by continuously scanning artifacts and gating releases based on severity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Managed services scale CI and artifact hosting without self-managing registries and scanners.<\/li>\n<li>Policy enforcement scales with deployments (for example, across multiple clusters) using consistent project-level policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Google Cloud Software supply chain security patterns when:\n&#8211; You deploy containers to <strong>GKE<\/strong> (or other supported runtimes) and want <strong>enforcement<\/strong>.\n&#8211; You need traceability and standardized, auditable build and release pipelines.\n&#8211; You\u2019re moving toward SLSA-style maturity and want stronger controls than \u201cbuild and push\u201d.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>It may not fit when:\n&#8211; You don\u2019t deploy containers (or have no runtime where Binary Authorization applies).\n&#8211; Your organization cannot standardize CI\/CD and artifact storage (e.g., many disconnected toolchains).\n&#8211; You require specialized scanning beyond what Google Cloud-native scanning supports for your artifact types (you may still integrate third-party scanners).\n&#8211; You\u2019re in a very constrained environment where managed build services are not allowed (e.g., strict air-gapped requirements), and you must self-host everything.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Software supply chain security used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Commonly adopted in:\n&#8211; Financial services and fintech\n&#8211; Healthcare and life sciences\n&#8211; Retail\/e-commerce\n&#8211; SaaS and enterprise software\n&#8211; Government and regulated industries\n&#8211; Media\/streaming (large-scale microservices)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams building golden paths<\/li>\n<li>DevOps and SRE teams standardizing CI\/CD<\/li>\n<li>Security engineering \/ AppSec teams implementing controls<\/li>\n<li>Development teams owning services end-to-end (with guardrails)<\/li>\n<li>Compliance and audit teams consuming evidence<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Containerized microservices<\/li>\n<li>Kubernetes workloads (GKE)<\/li>\n<li>Internal developer platforms (IDPs)<\/li>\n<li>API backends and batch processing containers<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-project environments (dev\/test\/prod separated)<\/li>\n<li>Multi-cluster deployments (regional resiliency)<\/li>\n<li>GitOps + CI\/CD pipelines<\/li>\n<li>Artifact promotion models (dev \u2192 staging \u2192 prod)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Production: strict policies (attestation required, vulnerability gates)<\/li>\n<li>Dev\/test: softer policies (warnings, lower severity gates) to reduce friction while still collecting data<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<p>A typical maturity approach:\n1. <strong>Observe<\/strong>: enable scanning\/metadata collection everywhere.\n2. <strong>Warn<\/strong>: alert on policy violations but don\u2019t block.\n3. <strong>Enforce in staging<\/strong>: require attestations and block high-severity vulnerabilities.\n4. <strong>Enforce in production<\/strong>: full gating, approvals, and controlled promotion.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios that align with how Software supply chain security is commonly implemented on Google Cloud.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Enforce \u201conly signed images run in production GKE\u201d<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Anyone with registry push access can publish an image that later gets deployed.<\/li>\n<li><strong>Why this fits:<\/strong> Binary Authorization can require an attestation signed by approved keys.<\/li>\n<li><strong>Example scenario:<\/strong> A platform team mandates that production namespaces only accept images attested by the CI system.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Prevent deploying images with known critical CVEs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams deploy quickly and miss high-severity vulnerabilities.<\/li>\n<li><strong>Why this fits:<\/strong> Artifact scanning + policy gates in CI and\/or deployment workflows reduce risk.<\/li>\n<li><strong>Example scenario:<\/strong> A release pipeline blocks promotion if critical vulnerabilities are detected (exact gating mechanism depends on your pipeline tooling).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Improve incident response with traceability (who built what)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> During an incident, you cannot quickly determine provenance of a running image.<\/li>\n<li><strong>Why this fits:<\/strong> Build logs, artifact metadata, and provenance help reconstruct chain of custody.<\/li>\n<li><strong>Example scenario:<\/strong> Security asks \u201cWhich commit produced this digest?\u201d and you can answer using CI metadata and artifact records (verify exact provenance features in Cloud Build docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Centralize artifact storage across teams and projects<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams store images in multiple registries, some without consistent IAM or logging.<\/li>\n<li><strong>Why this fits:<\/strong> Artifact Registry standardizes repositories, IAM, and audit trails.<\/li>\n<li><strong>Example scenario:<\/strong> Org migrates from scattered registries to Artifact Registry with per-team repos and standardized retention.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Separation of duties: builders sign, clusters verify<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Developers with cluster access can bypass controls.<\/li>\n<li><strong>Why this fits:<\/strong> Clusters enforce policy; only the signing system can create valid attestations.<\/li>\n<li><strong>Example scenario:<\/strong> Production cluster blocks all images without attestation from CI signing key stored in Cloud KMS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Secure multi-environment promotion (dev \u2192 staging \u2192 prod)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Builds in dev are not equivalent to prod deploys.<\/li>\n<li><strong>Why this fits:<\/strong> Promote the same digest across environments; use additional attestations at each stage.<\/li>\n<li><strong>Example scenario:<\/strong> Staging adds \u201cintegration-tested\u201d attestation; prod adds \u201capproved\u201d attestation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Reduce risk from compromised upstream OSS packages<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Dependency supply chain threats (typosquatting, compromised maintainers).<\/li>\n<li><strong>Why this fits:<\/strong> Assured OSS and curated sources reduce exposure (verify availability for your languages).<\/li>\n<li><strong>Example scenario:<\/strong> A team pulls base images and packages from curated sources and monitors vulnerabilities.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Standardize secure build execution with least privilege<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> CI runners have broad credentials and long-lived secrets.<\/li>\n<li><strong>Why this fits:<\/strong> Cloud Build uses IAM and service accounts; secrets can be sourced from Secret Manager.<\/li>\n<li><strong>Example scenario:<\/strong> Build steps access only needed resources; signing keys are never exposed as plaintext.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Enforce artifact immutability and digest-based deployments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Tags like <code>:latest<\/code> can be overwritten and lead to drift.<\/li>\n<li><strong>Why this fits:<\/strong> Deploy by digest; attestations bind to immutable digests.<\/li>\n<li><strong>Example scenario:<\/strong> Kubernetes manifests reference digests; deployment automation rejects tag-only images.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Compliance evidence for secure SDLC<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Auditors need proof of change control, approvals, and controlled releases.<\/li>\n<li><strong>Why this fits:<\/strong> CI logs, artifact metadata, KMS audit, and policy decisions are evidence.<\/li>\n<li><strong>Example scenario:<\/strong> Audit package includes build logs, attestation records, and deployment denials\/approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Protect against registry compromise blast radius<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> If a registry credential is compromised, attacker can push malicious images.<\/li>\n<li><strong>Why this fits:<\/strong> Attestation requirements prevent unsigned images from running, reducing impact.<\/li>\n<li><strong>Example scenario:<\/strong> An attacker pushes an image tag, but production cluster rejects due to missing attestation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Organization-wide security posture for CI\/CD<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Security practices vary by team.<\/li>\n<li><strong>Why this fits:<\/strong> Central platform patterns (registry, CI templates, policies) raise baseline.<\/li>\n<li><strong>Example scenario:<\/strong> Platform team provides standardized Cloud Build templates, Artifact Registry repos, and Binary Authorization policies.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Because Software supply chain security is implemented using multiple Google Cloud services, \u201cfeatures\u201d are best understood as the combined capabilities you can assemble.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Centralized artifact storage with IAM controls (Artifact Registry)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Stores container images and other artifacts in a managed registry with fine-grained IAM.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces uncontrolled artifact distribution and supports governance.<\/li>\n<li><strong>Practical benefit:<\/strong> Easier to apply uniform access policies and audit access.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Repository location and format support vary; verify available locations and formats in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Vulnerability scanning and artifact metadata (Artifact Registry + Container Analysis)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides vulnerability findings and metadata (\u201coccurrences\u201d) about stored artifacts.<\/li>\n<li><strong>Why it matters:<\/strong> Security teams need visibility into CVEs affecting deployed artifacts.<\/li>\n<li><strong>Practical benefit:<\/strong> Enables gating and prioritization of fixes.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Coverage varies by artifact type and configuration; scanning cadence and supported OS\/package types differ\u2014verify in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Deploy-time policy enforcement (Binary Authorization)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enforces policies so only compliant images can be deployed (commonly to GKE).<\/li>\n<li><strong>Why it matters:<\/strong> Prevents last-mile deployment of tampered or unverified images.<\/li>\n<li><strong>Practical benefit:<\/strong> Moves security checks from \u201cbest effort\u201d into enforced control.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Enforcement depends on supported runtimes and cluster configuration. Some features may be in specific GKE modes\/versions\u2014verify in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Cryptographic signing and key management (Cloud KMS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Stores and manages keys used to sign attestations and verify signatures.<\/li>\n<li><strong>Why it matters:<\/strong> Keys are a high-value target; KMS centralizes control, rotation, and audit.<\/li>\n<li><strong>Practical benefit:<\/strong> Avoids storing signing keys on developer machines or CI runners as plaintext.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> KMS is location-scoped; plan key location\/replication and IAM carefully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Controlled builds and build auditability (Cloud Build)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Runs builds in managed infrastructure, captures build logs, and integrates with IAM.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces risk from unmanaged CI runners and improves audit trails.<\/li>\n<li><strong>Practical benefit:<\/strong> Repeatable, centralized build execution with consistent identity.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Build environments and available builders have constraints; supply chain requires you to also secure your build configs and dependencies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Provenance\/traceability (build metadata and attestations)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Helps tie an artifact to how it was built (source, steps, builder identity). Google Cloud has features around build provenance; <strong>verify current Cloud Build provenance\/SLSA options<\/strong> in official docs.<\/li>\n<li><strong>Why it matters:<\/strong> Provenance is key to detecting tampering and proving origin.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster investigations and higher trust in artifacts.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Provenance is only as trustworthy as the build system and configuration; avoid \u201cbring your own\u201d insecure steps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Environment promotion and approvals (Cloud Deploy, optional)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Standardizes releases, promotions, and approval workflows.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces ad-hoc production changes and strengthens change management.<\/li>\n<li><strong>Practical benefit:<\/strong> Better operational consistency for multi-environment pipelines.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Adds another control-plane; ensure it integrates with your existing workflows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Central security visibility (Security Command Center, optional)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Aggregates findings across Google Cloud; can complement supply chain findings with broader security posture.<\/li>\n<li><strong>Why it matters:<\/strong> Supply chain is one part of the security picture.<\/li>\n<li><strong>Practical benefit:<\/strong> Central dashboards and alerting (depending on SCC tier and configuration).<\/li>\n<li><strong>Limitations\/caveats:<\/strong> SCC features vary by edition\/tier; verify current SCC pricing and feature set.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Curated and hardened OSS inputs (Assured OSS, optional)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides curated open-source packages\/images (scope depends on Google Cloud offering).<\/li>\n<li><strong>Why it matters:<\/strong> Reduces risk from upstream compromise.<\/li>\n<li><strong>Practical benefit:<\/strong> More confidence in base dependencies.<\/li>\n<li><strong>Limitations\/caveats:<\/strong> Not universal across all languages and packages; verify what\u2019s supported and how it\u2019s consumed.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>A typical Google Cloud Software supply chain security architecture has these phases:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Source<\/strong>: Code in a Git provider (GitHub\/GitLab\/Bitbucket or other).<\/li>\n<li><strong>Build<\/strong>: Cloud Build executes CI steps using a service account.<\/li>\n<li><strong>Store<\/strong>: Output image is pushed to Artifact Registry.<\/li>\n<li><strong>Analyze<\/strong>: Container Analysis records vulnerabilities\/metadata.<\/li>\n<li><strong>Attest<\/strong>: A trusted signer (CI) creates an attestation for the immutable image digest using Cloud KMS.<\/li>\n<li><strong>Deploy<\/strong>: GKE attempts to deploy the image.<\/li>\n<li><strong>Enforce<\/strong>: Binary Authorization evaluates policy and attestations; deploy allowed\/denied.<\/li>\n<li><strong>Observe<\/strong>: Logs and metrics go to Cloud Logging\/Monitoring; optionally SCC aggregates.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (conceptual)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Data flow:<\/strong> source \u2192 build \u2192 artifact \u2192 deploy<\/li>\n<li><strong>Control flow:<\/strong> IAM policies, Binary Authorization policy, KMS signing permissions<\/li>\n<li><strong>Security flow:<\/strong> scanning metadata \u2192 gating decisions \u2192 enforcement logs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>IAM<\/strong>: service accounts for build and deploy; least privilege.\n&#8211; <strong>Cloud Logging<\/strong>: build logs, registry access logs, KMS audit logs, GKE audit logs.\n&#8211; <strong>Secret Manager<\/strong>: store tokens (if needed) and build secrets.\n&#8211; <strong>VPC Service Controls<\/strong> (advanced): reduce data exfiltration risk for supported services (verify compatibility and design carefully).\n&#8211; <strong>Organization Policy Service<\/strong>: enforce constraints (where applicable).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>A minimal secure pipeline typically needs:\n&#8211; Cloud Build\n&#8211; Artifact Registry\n&#8211; Container Analysis\n&#8211; Cloud KMS\n&#8211; Binary Authorization\n&#8211; GKE (for enforcement demonstration)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Users<\/strong> authenticate via Google Identity and IAM.<\/li>\n<li><strong>Build<\/strong> runs under a <strong>Cloud Build service account<\/strong> (or a custom service account).<\/li>\n<li><strong>Kubernetes<\/strong> pull access is controlled via IAM to Artifact Registry plus node\/workload identity configuration.<\/li>\n<li><strong>Attestation signing<\/strong> is permitted only to a controlled identity with KMS permissions.<\/li>\n<li><strong>Binary Authorization<\/strong> validates attestations using configured public keys.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Artifact Registry and Cloud Build are Google-managed services accessed over Google APIs.<\/li>\n<li>GKE pulls images from Artifact Registry endpoints.<\/li>\n<li>For advanced environments:<\/li>\n<li>use <strong>Private Google Access<\/strong> and\/or <strong>Private Service Connect<\/strong> where supported and appropriate (verify per-service support).<\/li>\n<li>restrict egress and apply firewall rules for nodes and build workers where applicable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Track:<\/li>\n<li>Cloud Build build history and failures<\/li>\n<li>Artifact Registry access (who pushed\/pulled)<\/li>\n<li>Container Analysis vulnerability trends<\/li>\n<li>Binary Authorization denials<\/li>\n<li>KMS key usage and admin changes<\/li>\n<li>GKE audit logs for deployments<\/li>\n<li>Governance:<\/li>\n<li>standardized naming for repos, attestors, keys<\/li>\n<li>labels\/tags on resources for cost allocation<\/li>\n<li>separate projects for dev\/staging\/prod<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (conceptual)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Developer] --&gt;|git push| Git[Git Provider]\n  Git --&gt; CB[Cloud Build]\n  CB --&gt; AR[Artifact Registry]\n  AR --&gt; CA[Container Analysis]\n  CB --&gt;|sign attestation| KMS[Cloud KMS]\n  KMS --&gt; BA[Binary Authorization Policy]\n  AR --&gt; GKE[GKE Cluster]\n  BA --&gt;|allow\/deny| GKE\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (multi-environment)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Source[Source Control]\n    GitHub[GitHub \/ GitLab]\n  end\n\n  subgraph Build[Build Project]\n    CB[Cloud Build]\n    SM[Secret Manager]\n    KMS1[Cloud KMS - Signing Keys]\n    Logs1[Cloud Logging]\n  end\n\n  subgraph Artifacts[Central Artifacts Project]\n    AR[Artifact Registry]\n    CA[Container Analysis \/ Vulnerability Data]\n  end\n\n  subgraph Deploy[Deployment Projects]\n    CD[Cloud Deploy (optional)]\n    BA[Binary Authorization Policy]\n    GKEstg[GKE Staging]\n    GKEprd[GKE Production]\n    Logs2[Cloud Logging + GKE Audit Logs]\n  end\n\n  GitHub --&gt; CB\n  SM --&gt; CB\n  CB --&gt; AR\n  AR --&gt; CA\n  CB --&gt; KMS1\n  KMS1 --&gt; BA\n  CD --&gt; GKEstg\n  CD --&gt; GKEprd\n  AR --&gt; GKEstg\n  AR --&gt; GKEprd\n  BA --&gt; GKEstg\n  BA --&gt; GKEprd\n  CB --&gt; Logs1\n  GKEstg --&gt; Logs2\n  GKEprd --&gt; Logs2\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>billing enabled<\/strong>.<\/li>\n<li>Ability to create\/manage:<\/li>\n<li>Artifact Registry repositories<\/li>\n<li>Cloud Build triggers\/builds<\/li>\n<li>KMS keys<\/li>\n<li>GKE clusters<\/li>\n<li>Binary Authorization policies\/attestors<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions\/IAM roles (minimum suggested for the lab)<\/h3>\n\n\n\n<p>Exact roles vary by organization policy. For a hands-on lab in a personal sandbox project, you may use broader roles; for production, use least privilege.<\/p>\n\n\n\n<p>Typical roles you\u2019ll need (verify in docs):\n&#8211; Artifact Registry admin: <code>roles\/artifactregistry.admin<\/code>\n&#8211; Cloud Build editor\/admin: <code>roles\/cloudbuild.builds.editor<\/code> (or admin as needed)\n&#8211; GKE admin: <code>roles\/container.admin<\/code>\n&#8211; Binary Authorization admin: <code>roles\/binaryauthorization.admin<\/code>\n&#8211; KMS admin for key creation: <code>roles\/cloudkms.admin<\/code>\n&#8211; Service Usage admin to enable APIs: <code>roles\/serviceusage.serviceUsageAdmin<\/code>\n&#8211; Viewer roles for verification: <code>roles\/viewer<\/code>, plus service-specific viewers<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>This lab can incur costs from:<\/li>\n<li>GKE cluster and node compute<\/li>\n<li>Cloud Build build minutes<\/li>\n<li>Artifact Registry storage and network egress (usually small for a tiny demo)<\/li>\n<li>Cloud KMS key versions and operations<\/li>\n<li>Logging ingestion (typically small for a lab)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/cloud.google.com\/sdk\/docs\/install\">Google Cloud SDK (<code>gcloud<\/code>)<\/a><\/li>\n<li><code>kubectl<\/code> (installed via <code>gcloud components install kubectl<\/code> or your OS package manager; verify current guidance)<\/li>\n<li>Docker (optional; we\u2019ll use Cloud Build so local Docker is not required)<\/li>\n<li>A text editor<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Choose a region where <strong>GKE<\/strong>, <strong>Artifact Registry<\/strong>, and <strong>Cloud KMS<\/strong> are available.<\/li>\n<li>Verify locations for Artifact Registry and KMS:  <\/li>\n<li>Artifact Registry locations: https:\/\/cloud.google.com\/artifact-registry\/docs\/repositories\/repo-locations  <\/li>\n<li>KMS locations: https:\/\/cloud.google.com\/kms\/docs\/locations<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Common quota areas (verify in your project quotas):\n&#8211; GKE cluster and node quotas (CPUs, clusters)\n&#8211; Artifact Registry storage\/requests\n&#8211; Cloud Build concurrent builds\n&#8211; KMS key operations<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs to enable<\/h3>\n\n\n\n<p>For the lab, you will typically enable:\n&#8211; Kubernetes Engine API\n&#8211; Artifact Registry API\n&#8211; Cloud Build API\n&#8211; Container Analysis API\n&#8211; Binary Authorization API\n&#8211; Cloud KMS API<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Software supply chain security on Google Cloud is <strong>not a single billable line item<\/strong>. Your costs come from the services you use to implement it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<p>Typical pricing drivers include:<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Cloud Build<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build minutes\/seconds (varies by worker type\/size and configuration)<\/li>\n<li>Any additional resources used in builds (network egress, storage)<\/li>\n<li>Pricing: https:\/\/cloud.google.com\/build\/pricing<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Artifact Registry<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Storage (GB-month)<\/li>\n<li>Data transfer\/egress (especially cross-region or to the internet)<\/li>\n<li>Requests\/operations may be priced depending on artifact format and features\u2014verify current pricing details<\/li>\n<li>Pricing: https:\/\/cloud.google.com\/artifact-registry\/pricing<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">GKE<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cluster management fee (mode-dependent) plus node compute\/storage\/network<\/li>\n<li>Autopilot vs Standard have different cost models<\/li>\n<li>Pricing: https:\/\/cloud.google.com\/kubernetes-engine\/pricing<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Cloud KMS<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Key versions (active)<\/li>\n<li>Key operations (sign, verify, encrypt\/decrypt depending on key type)<\/li>\n<li>Pricing: https:\/\/cloud.google.com\/kms\/pricing<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Container Analysis \/ vulnerability scanning<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Often tied to Artifact Registry scanning features and Container Analysis usage.<\/li>\n<li>Pricing and inclusions can change; <strong>verify current pricing<\/strong> from official sources:<\/li>\n<li>Container Analysis docs: https:\/\/cloud.google.com\/container-analysis\/docs<\/li>\n<li>Artifact Registry scanning docs\/pricing notes: https:\/\/cloud.google.com\/artifact-registry\/docs<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Logging\/Monitoring<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Logs ingestion and retention beyond free allotments can cost.<\/li>\n<li>Pricing: https:\/\/cloud.google.com\/stackdriver\/pricing (Cloud Operations pricing page)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier (if applicable)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some services have free tiers or free quotas (e.g., limited Cloud Build minutes, logging allotments). These change over time and vary by account\/project. <strong>Verify in official pricing pages<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>GKE nodes<\/strong> (biggest cost in many labs\/PoCs)<\/li>\n<li><strong>High-frequency builds<\/strong> (many commits + heavy build steps)<\/li>\n<li><strong>Large images<\/strong> stored across multiple repos\/regions<\/li>\n<li><strong>Cross-region pulls<\/strong> (e.g., cluster in region A pulling images from region B)<\/li>\n<li><strong>KMS signing operations<\/strong> at high volume (if signing every build\/artifact frequently)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data egress from Artifact Registry to on-prem or other clouds<\/li>\n<li>Extra logging retention for audit\/compliance<\/li>\n<li>Security tooling integrations (SIEM export, SCC tier upgrades)<\/li>\n<li>Developer time to maintain policies and exceptions<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep Artifact Registry in the <strong>same region<\/strong> as GKE clusters when possible.<\/li>\n<li>Minimize cross-region artifact replication unless needed for resiliency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use a single small GKE cluster for dev\/test, and scale down when idle.<\/li>\n<li>Keep demo images small; use slim base images.<\/li>\n<li>Store fewer artifacts via retention policies (verify Artifact Registry cleanup\/retention options).<\/li>\n<li>Use build caching where appropriate (Cloud Build supports caching patterns\u2014verify latest options).<\/li>\n<li>Reduce unnecessary signing operations (sign once per digest, not per deployment attempt).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated prices)<\/h3>\n\n\n\n<p>A low-cost starter lab typically includes:\n&#8211; 1 small GKE cluster (most of the cost)\n&#8211; A few Cloud Build runs (small container build)\n&#8211; A small Artifact Registry repo (few hundred MB at most)\n&#8211; A single KMS key with a few signing operations<\/p>\n\n\n\n<p>Because exact prices vary by <strong>region<\/strong>, <strong>GKE mode<\/strong>, and current SKUs, use:\n&#8211; Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production at scale, cost planning should include:\n&#8211; CI build concurrency and worker sizing\n&#8211; Artifact retention and replication strategy\n&#8211; Cluster fleet size and environment count\n&#8211; Logging retention for audit requirements\n&#8211; KMS operation volume for signing\/verification patterns\n&#8211; Potential SCC tier costs if you centralize findings there (verify SCC pricing)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Build and deploy a container image securely on Google Cloud by:\n1. Building the image with Cloud Build\n2. Storing it in Artifact Registry\n3. Enforcing deploy-time admission control on GKE using Binary Authorization\n4. Creating an attestation signed by Cloud KMS so the deployment is allowed<\/p>\n\n\n\n<p>This lab demonstrates a core Software supply chain security pattern: <strong>\u201conly attested images can run.\u201d<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n&#8211; Create an Artifact Registry repo\n&#8211; Build and push a container image with Cloud Build\n&#8211; Create a GKE cluster and enable Binary Authorization enforcement\n&#8211; Create a KMS asymmetric signing key\n&#8211; Create a Binary Authorization attestor using that key\n&#8211; Attempt a deployment (expect it to be denied)\n&#8211; Create an attestation for the image digest\n&#8211; Deploy again (expect it to succeed)\n&#8211; Clean up all resources<\/p>\n\n\n\n<blockquote>\n<p>Cost note: GKE is the main cost driver. Complete cleanup at the end.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set environment variables and select a project<\/h3>\n\n\n\n<p>Choose a project with billing enabled.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\nexport REGION=\"us-central1\"\nexport ZONE=\"us-central1-a\"\nexport REPO=\"ssc-lab-repo\"\nexport IMAGE=\"hello-ssc\"\nexport CLUSTER=\"ssc-lab-gke\"\nexport KMS_KEYRING=\"ssc-lab-kr\"\nexport KMS_KEY=\"ssc-lab-signing-key\"\nexport ATTESTOR=\"ssc-lab-attestor\"\n<\/code><\/pre>\n\n\n\n<p>Set your project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project \"${PROJECT_ID}\"\ngcloud config set compute\/region \"${REGION}\"\ngcloud config set compute\/zone \"${ZONE}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>gcloud<\/code> now targets your project\/region\/zone.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable required APIs<\/h3>\n\n\n\n<p>Enable the core APIs used in this lab:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  artifactregistry.googleapis.com \\\n  cloudbuild.googleapis.com \\\n  container.googleapis.com \\\n  containeranalysis.googleapis.com \\\n  binaryauthorization.googleapis.com \\\n  cloudkms.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs are enabled successfully.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:artifactregistry.googleapis.com OR name:cloudbuild.googleapis.com OR name:container.googleapis.com OR name:binaryauthorization.googleapis.com OR name:cloudkms.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create an Artifact Registry Docker repository<\/h3>\n\n\n\n<p>Create a Docker repository in Artifact Registry:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories create \"${REPO}\" \\\n  --repository-format=docker \\\n  --location=\"${REGION}\" \\\n  --description=\"Software supply chain security lab repo\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Repository exists in <code>${REGION}<\/code>.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories list --location=\"${REGION}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a small containerized app locally (source only)<\/h3>\n\n\n\n<p>Create a working directory:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p ssc-lab &amp;&amp; cd ssc-lab\n<\/code><\/pre>\n\n\n\n<p>Create <code>main.py<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; main.py &lt;&lt;'EOF'\nfrom flask import Flask\nimport os\n\napp = Flask(__name__)\n\n@app.get(\"\/\")\ndef hello():\n    return {\n        \"message\": \"Hello from Software supply chain security lab\",\n        \"service\": os.getenv(\"K_SERVICE\", \"local\")\n    }\n\nif __name__ == \"__main__\":\n    app.run(host=\"0.0.0.0\", port=int(os.getenv(\"PORT\", \"8080\")))\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create <code>requirements.txt<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; requirements.txt &lt;&lt;'EOF'\nflask==3.0.3\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create <code>Dockerfile<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; Dockerfile &lt;&lt;'EOF'\nFROM python:3.12-slim\n\nWORKDIR \/app\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\n\nCOPY main.py .\nENV PORT=8080\nEXPOSE 8080\n\nCMD [\"python\", \"main.py\"]\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have a minimal app and Dockerfile ready for Cloud Build.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Build and push the image using Cloud Build<\/h3>\n\n\n\n<p>Define the full image path:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export IMAGE_PATH=\"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\/${IMAGE}\"\necho \"${IMAGE_PATH}\"\n<\/code><\/pre>\n\n\n\n<p>Submit the build:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud builds submit --tag \"${IMAGE_PATH}:v1\" .\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud Build builds the container and pushes it to Artifact Registry with tag <code>v1<\/code>.<\/p>\n\n\n\n<p><strong>Verification (list images):<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts docker images list \"${REGION}-docker.pkg.dev\/${PROJECT_ID}\/${REPO}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Capture the immutable image digest<\/h3>\n\n\n\n<p>Binary Authorization works best with immutable digests.<\/p>\n\n\n\n<p>Get the image digest:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export DIGEST=$(gcloud artifacts docker images describe \"${IMAGE_PATH}:v1\" \\\n  --format=\"value(image_summary.digest)\")\necho \"${DIGEST}\"\n<\/code><\/pre>\n\n\n\n<p>Construct a digest-pinned reference:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export IMAGE_BY_DIGEST=\"${IMAGE_PATH}@${DIGEST}\"\necho \"${IMAGE_BY_DIGEST}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have an immutable image reference like <code>...\/hello-ssc@sha256:...<\/code>.<\/p>\n\n\n\n<blockquote>\n<p>If <code>gcloud artifacts docker images describe<\/code> output differs in your environment, <strong>verify the current <code>gcloud artifacts<\/code> commands<\/strong> in the Artifact Registry documentation:\nhttps:\/\/cloud.google.com\/artifact-registry\/docs<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: (Optional but recommended) Review vulnerability findings in Artifact Registry<\/h3>\n\n\n\n<p>Artifact vulnerability scanning visibility is commonly accessed via the console.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Go to: Google Cloud Console \u2192 <strong>Artifact Registry<\/strong> \u2192 <strong>Repositories<\/strong> \u2192 <code>${REPO}<\/code><\/li>\n<li>Open the image \u2192 review the <strong>Vulnerabilities<\/strong> tab (if available for your configuration)<\/li>\n<\/ul>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can see vulnerability findings\/metadata for the image (may take time to populate, and availability varies).<br\/>\nIf you do not see findings, verify scanning is enabled\/supported for your repo\/location\/artifact type in official docs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a GKE cluster and enable Binary Authorization enforcement<\/h3>\n\n\n\n<p>Create a small cluster (choose Autopilot or Standard based on your preference). The exact flags and best choice depend on your environment and quotas.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A: GKE Autopilot (simpler operations)<\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters create-auto \"${CLUSTER}\" \\\n  --region \"${REGION}\"\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: GKE Standard (more control; you manage nodes)<\/h4>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters create \"${CLUSTER}\" \\\n  --zone \"${ZONE}\" \\\n  --num-nodes 1\n<\/code><\/pre>\n\n\n\n<p>Enable Binary Authorization enforcement on the cluster.<\/p>\n\n\n\n<p>For many setups, you can set evaluation mode to enforce the <strong>project<\/strong> policy. Verify the exact flag support for your cluster mode\/version in the Binary Authorization + GKE docs.<\/p>\n\n\n\n<p>Example (verify current flags in docs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters update \"${CLUSTER}\" \\\n  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \\\n  --zone \"${ZONE}\" 2&gt;\/dev\/null || \\\ngcloud container clusters update \"${CLUSTER}\" \\\n  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \\\n  --region \"${REGION}\"\n<\/code><\/pre>\n\n\n\n<p>Get cluster credentials:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters get-credentials \"${CLUSTER}\" \\\n  --zone \"${ZONE}\" 2&gt;\/dev\/null || \\\ngcloud container clusters get-credentials \"${CLUSTER}\" \\\n  --region \"${REGION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can run <code>kubectl<\/code> against the cluster, and the cluster is configured to enforce Binary Authorization project policy.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get nodes\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Create a Cloud KMS asymmetric signing key<\/h3>\n\n\n\n<p>Create a key ring:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud kms keyrings create \"${KMS_KEYRING}\" \\\n  --location \"${REGION}\"\n<\/code><\/pre>\n\n\n\n<p>Create an asymmetric signing key (elliptic curve P-256 is commonly used; verify supported algorithms and current best practices):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud kms keys create \"${KMS_KEY}\" \\\n  --keyring \"${KMS_KEYRING}\" \\\n  --location \"${REGION}\" \\\n  --purpose asymmetric-signing \\\n  --default-algorithm ec-sign-p256-sha256\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> KMS key exists and can be used for signing attestations.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud kms keys list --keyring \"${KMS_KEYRING}\" --location \"${REGION}\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Create a Binary Authorization attestor and bind the KMS key<\/h3>\n\n\n\n<p>Create an attestor:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestors create \"${ATTESTOR}\" \\\n  --attestation-authority-note=\"${ATTESTOR}-note\" \\\n  --attestation-authority-note-project=\"${PROJECT_ID}\"\n<\/code><\/pre>\n\n\n\n<p>Add a public key to the attestor by referencing the KMS key version. First, get the key version resource name:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export KEY_VERSION=$(gcloud kms keys versions list \\\n  --key \"${KMS_KEY}\" \\\n  --keyring \"${KMS_KEYRING}\" \\\n  --location \"${REGION}\" \\\n  --format=\"value(name)\" | head -n 1)\n\necho \"${KEY_VERSION}\"\n<\/code><\/pre>\n\n\n\n<p>Now add the KMS key version to the attestor:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestors public-keys add \\\n  --attestor=\"${ATTESTOR}\" \\\n  --keyversion=\"${KEY_VERSION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Attestor exists with a public key that can verify signatures from your KMS key.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestors describe \"${ATTESTOR}\"\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Command groups for Binary Authorization can change across <code>gcloud<\/code> versions. If a command is not recognized, verify current CLI commands in official docs:\nhttps:\/\/cloud.google.com\/binary-authorization\/docs<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 11: Create a Binary Authorization policy that requires your attestor<\/h3>\n\n\n\n<p>Set a policy requiring attestations for all images by default, and allow only images attested by <code>${ATTESTOR}<\/code>.<\/p>\n\n\n\n<p>This is a powerful setting\u2014use carefully in real environments.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz policy import &lt;&lt;EOF\ndefaultAdmissionRule:\n  evaluationMode: REQUIRE_ATTESTATION\n  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG\n  requireAttestationsBy:\n  - projects\/${PROJECT_ID}\/attestors\/${ATTESTOR}\nEOF\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The policy is active. Any deploy that lacks the required attestation should be denied.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz policy export\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 12: Attempt to deploy without an attestation (expect denial)<\/h3>\n\n\n\n<p>Create a namespace:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl create namespace ssc-demo\n<\/code><\/pre>\n\n\n\n<p>Deploy using the digest reference:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n ssc-demo create deployment hello-ssc --image=\"${IMAGE_BY_DIGEST}\"\n<\/code><\/pre>\n\n\n\n<p>Watch events:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n ssc-demo get events --sort-by=.metadata.creationTimestamp\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The deployment should fail admission due to Binary Authorization policy (denied because no attestation exists).<\/p>\n\n\n\n<p>If the deployment appears to succeed, check:\n&#8211; Is Binary Authorization enforcement enabled on the cluster?\n&#8211; Is the evaluation mode set correctly?\n&#8211; Are you deploying by digest?\n&#8211; Are there policy exceptions?<br\/>\nUse troubleshooting below.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 13: Create an attestation for the image digest (sign with Cloud KMS)<\/h3>\n\n\n\n<p>Now create the attestation that will satisfy the policy.<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestations sign-and-create \\\n  --artifact-url=\"${IMAGE_BY_DIGEST}\" \\\n  --attestor=\"${ATTESTOR}\" \\\n  --keyversion=\"${KEY_VERSION}\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> An attestation is created for the image digest.<\/p>\n\n\n\n<p><strong>Verification (describe attestations):<\/strong>\nBinary Authorization attestation listing commands vary; if listing isn\u2019t available or differs, verify using docs. You can also simply re-deploy and confirm it succeeds.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 14: Deploy again (expect success)<\/h3>\n\n\n\n<p>Delete the failed deployment (if created) and redeploy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n ssc-demo delete deployment hello-ssc --ignore-not-found\nkubectl -n ssc-demo create deployment hello-ssc --image=\"${IMAGE_BY_DIGEST}\"\n<\/code><\/pre>\n\n\n\n<p>Expose it via a LoadBalancer service (for a quick demo). This may create a cloud load balancer that can cost money; for lower-cost, use <code>kubectl port-forward<\/code> instead.<\/p>\n\n\n\n<p><strong>Option A: Port-forward (lowest cost)<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n ssc-demo port-forward deployment\/hello-ssc 8080:8080\n<\/code><\/pre>\n\n\n\n<p>In another terminal:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s http:\/\/127.0.0.1:8080\/ | python -m json.tool\n<\/code><\/pre>\n\n\n\n<p><strong>Option B: LoadBalancer (costs more; simple external test)<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n ssc-demo expose deployment hello-ssc --type=LoadBalancer --port 80 --target-port 8080\nkubectl -n ssc-demo get svc\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The deployment is admitted and pods become Running. The app returns JSON with the hello message.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use these checks:<\/p>\n\n\n\n<p>1) Confirm the pod is running:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n ssc-demo get pods -o wide\n<\/code><\/pre>\n\n\n\n<p>2) Confirm the image digest is used:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n ssc-demo get pod -o jsonpath='{.items[0].spec.containers[0].image}{\"\\n\"}'\n<\/code><\/pre>\n\n\n\n<p>3) Confirm Binary Authorization enforcement is active:\n&#8211; Attempt to deploy a different, non-attested digest and confirm it is denied.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Deployment is not denied even without attestation<\/h4>\n\n\n\n<p>Possible causes:\n&#8211; Binary Authorization not enabled on the cluster or not enforcing project policy.\n&#8211; Policy isn\u2019t set to <code>ENFORCED_BLOCK_AND_AUDIT_LOG<\/code>.\n&#8211; You are deploying by tag rather than digest (policy\/attestation mismatches are common).\n&#8211; You deployed to a different cluster than expected.<\/p>\n\n\n\n<p>Fixes:\n&#8211; Re-check cluster setting (verify current command\/flag support):\n  &#8211; https:\/\/cloud.google.com\/binary-authorization\/docs\n  &#8211; https:\/\/cloud.google.com\/kubernetes-engine\/docs\n&#8211; Export the policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz policy export\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: <code>gcloud container binauthz ...<\/code> commands not found<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your Cloud SDK may be outdated.<\/li>\n<li>Update gcloud:<\/li>\n<li>https:\/\/cloud.google.com\/sdk\/docs\/update-gcloud<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Attestation creation fails with permissions<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure your user (or the identity running the command) can:<\/li>\n<li>sign using the KMS key version<\/li>\n<li>manage Binary Authorization attestations\/attestors<\/li>\n<li>Check IAM on the KMS key and Binary Authorization resources.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Issue: Artifact Registry commands differ<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>gcloud artifacts<\/code> subcommands can evolve.<\/li>\n<li>Verify current commands in official docs:<\/li>\n<li>https:\/\/cloud.google.com\/artifact-registry\/docs<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, remove resources.<\/p>\n\n\n\n<p>Delete Kubernetes resources:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl delete namespace ssc-demo --ignore-not-found\n<\/code><\/pre>\n\n\n\n<p>Delete the GKE cluster:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters delete \"${CLUSTER}\" --zone \"${ZONE}\" --quiet 2&gt;\/dev\/null || \\\ngcloud container clusters delete \"${CLUSTER}\" --region \"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete Binary Authorization policy (set to permissive) or remove the policy:\nTo avoid breaking other deployments, you can set it back to <code>ALWAYS_ALLOW<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz policy import &lt;&lt;EOF\ndefaultAdmissionRule:\n  evaluationMode: ALWAYS_ALLOW\n  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG\nEOF\n<\/code><\/pre>\n\n\n\n<p>Delete the attestor:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container binauthz attestors delete \"${ATTESTOR}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete Artifact Registry repository:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories delete \"${REPO}\" --location \"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Delete KMS key ring (deletes keys inside):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud kms keyrings delete \"${KMS_KEYRING}\" --location \"${REGION}\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Optionally delete build history\/artifacts if needed (build logs remain in Cloud Logging per retention settings).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate projects<\/strong> for build, artifacts, and runtime (dev\/staging\/prod) to reduce blast radius.<\/li>\n<li>Use <strong>digest-based deployments<\/strong> to ensure immutability.<\/li>\n<li>Implement <strong>promotion<\/strong> (same digest moves through environments) rather than rebuilding per environment.<\/li>\n<li>Treat policy and CI templates as <strong>platform products<\/strong>: documented, versioned, and reviewed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>least privilege<\/strong>:<\/li>\n<li>Cloud Build service account can push to specific repos only.<\/li>\n<li>Only a controlled signer identity can use KMS signing permissions.<\/li>\n<li>GKE nodes\/workloads have pull-only permissions where needed.<\/li>\n<li>Prefer <strong>short-lived credentials<\/strong> and Google-managed identity patterns over stored keys.<\/li>\n<li>Restrict who can change:<\/li>\n<li>Binary Authorization policies<\/li>\n<li>KMS keys\/versions<\/li>\n<li>Artifact Registry IAM bindings<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep Artifact Registry and GKE in the same region to reduce cross-region egress.<\/li>\n<li>Use lifecycle\/retention strategies to avoid storing every build forever.<\/li>\n<li>Optimize container image size to reduce storage and pull costs.<\/li>\n<li>Right-size GKE clusters; shut down non-prod clusters when not needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use build caching where supported (verify current Cloud Build caching features).<\/li>\n<li>Minimize base image layers and package installs.<\/li>\n<li>Use regional Artifact Registry close to clusters to reduce pull latency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>regional GKE clusters<\/strong> for production if you need higher availability.<\/li>\n<li>Consider artifact replication strategies if multi-region resiliency is required (verify Artifact Registry options).<\/li>\n<li>Ensure KMS key availability aligns with your signing\/verification needs (regional vs multi-regional considerations).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor:<\/li>\n<li>Binary Authorization denials (these are high-signal security events)<\/li>\n<li>Artifact Registry push\/pull anomalies<\/li>\n<li>High severity vulnerabilities in frequently deployed images<\/li>\n<li>Establish exception processes:<\/li>\n<li>break-glass policy changes with approvals<\/li>\n<li>temporary policy exemptions with expiry and review<\/li>\n<li>Build runbooks for:<\/li>\n<li>\u201cdeployment blocked by policy\u201d<\/li>\n<li>\u201ccritical CVE found in prod image\u201d<\/li>\n<li>\u201csigning key rotation\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize names:<\/li>\n<li>repos: <code>team-app-env<\/code><\/li>\n<li>attestors: <code>env-purpose-attestor<\/code><\/li>\n<li>KMS keys: <code>purpose-env-key<\/code><\/li>\n<li>Apply labels for cost allocation and ownership:<\/li>\n<li><code>team<\/code>, <code>env<\/code>, <code>app<\/code>, <code>cost-center<\/code><\/li>\n<li>Use organization policies where applicable to enforce baseline constraints (verify which constraints apply to your chosen services).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Software supply chain security is fundamentally about <strong>controlling identities<\/strong> across:<\/li>\n<li>source changes<\/li>\n<li>build execution<\/li>\n<li>artifact publishing<\/li>\n<li>signing\/attestation<\/li>\n<li>deployment<\/li>\n<li>Use separate service accounts for:<\/li>\n<li>build<\/li>\n<li>deploy<\/li>\n<li>signing (or signing step within build with tight IAM)<\/li>\n<li>Limit admin roles to a small group; use break-glass accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud encrypts data at rest by default; for higher control:<\/li>\n<li>consider <strong>CMEK<\/strong> for supported services (verify per-service support)<\/li>\n<li>Use Cloud KMS\/HSM if required by compliance (verify Cloud HSM options if needed).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid public cluster endpoints where not required; use private clusters if appropriate.<\/li>\n<li>Limit egress from build environments if possible (hard in general CI; use policy and allowlists where applicable).<\/li>\n<li>Keep registries regional and access-controlled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Store tokens and sensitive values in <strong>Secret Manager<\/strong>.<\/li>\n<li>Avoid embedding secrets in:<\/li>\n<li>Dockerfiles<\/li>\n<li>build configs committed to source<\/li>\n<li>Kubernetes manifests<\/li>\n<li>Prefer workload identity approaches over static keys.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<p>Enable and monitor:\n&#8211; Cloud Build logs (who triggered builds)\n&#8211; Artifact Registry audit logs (push\/pull, IAM changes)\n&#8211; Cloud KMS audit logs (sign operations, key admin)\n&#8211; GKE audit logs (deploy attempts and rejections)\n&#8211; Binary Authorization policy changes and denials<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Supply chain controls can support requirements in many frameworks, but mapping is implementation-specific. Typical evidence artifacts:\n&#8211; build logs and approvals\n&#8211; attestation records\n&#8211; vulnerability scan outputs\n&#8211; policy configuration and change history\n&#8211; access logs and key usage logs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploying by <strong>tag<\/strong> and assuming it\u2019s immutable.<\/li>\n<li>Allowing many identities to <strong>sign attestations<\/strong> or access signing keys.<\/li>\n<li>Treating vulnerability scanning as \u201cset and forget\u201d without triage workflows.<\/li>\n<li>Using broad IAM roles (e.g., project editor) for CI.<\/li>\n<li>Allowing policy exceptions without expiry and review.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce in stages:\n  1) collect data\n  2) warn\n  3) enforce in staging\n  4) enforce in prod<\/li>\n<li>Keep signing keys protected and rotate them.<\/li>\n<li>Use separate attestors for different trust levels (build passed, tests passed, approved).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (solution-level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Because Software supply chain security is multi-service, you must design:<\/li>\n<li>ownership boundaries<\/li>\n<li>consistent IAM<\/li>\n<li>consistent environment promotion<\/li>\n<li>Enforcement is strongest when your runtime supports it (commonly GKE). Other runtimes may have different support\u2014verify current Binary Authorization coverage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>GKE CPU quotas and cluster quotas can block labs.<\/li>\n<li>Cloud Build concurrency quotas can affect CI at scale.<\/li>\n<li>KMS API quotas can affect high-volume signing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>KMS keys are location-scoped; choose location deliberately.<\/li>\n<li>Artifact Registry repos are location-scoped; mismatch with cluster region can add latency\/egress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>LoadBalancer services in GKE can cost money quickly.<\/li>\n<li>Logging retention beyond defaults can become significant at scale.<\/li>\n<li>Cross-region artifact pulls generate network egress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Attestations typically bind to <strong>image digests<\/strong>, not tags. If your deploy tooling rewrites tags, you can see unexpected policy denials.<\/li>\n<li>Some <code>gcloud<\/code> commands evolve; always verify current syntax in official docs for Binary Authorization and Artifact Registry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Policy enforcement can block deployments unexpectedly if:<\/li>\n<li>signing pipeline is down<\/li>\n<li>KMS permissions change<\/li>\n<li>image is rebuilt and digest changes<\/li>\n<li>Key rotation requires coordination:<\/li>\n<li>add new key version to attestor<\/li>\n<li>sign with new key<\/li>\n<li>retire old key only after all needed images are covered<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating from Container Registry or other registries to Artifact Registry requires careful update of:<\/li>\n<li>image references<\/li>\n<li>IAM permissions<\/li>\n<li>CI pipelines<\/li>\n<li>cluster pull permissions<\/li>\n<li>Moving from \u201ctag-based\u201d to \u201cdigest-based\u201d deployments requires changes in release tooling and developer habits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud services integrate deeply with IAM and audit logs; this is a strength but requires IAM discipline.<\/li>\n<li>Binary Authorization policy design strongly affects developer experience\u2014start simple, iterate, document exceptions.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Software supply chain security is a broad discipline. Here\u2019s how Google Cloud\u2019s approach compares to nearby options.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives inside Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Third-party scanners integrated into Cloud Build or Artifact Registry<\/li>\n<li>Policy enforcement via admission controllers (e.g., OPA Gatekeeper\/Policy Controller) for Kubernetes configuration policies (complements Binary Authorization; it\u2019s not the same as artifact attestation)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS<\/strong>: ECR + Inspector scanning, AWS Signer (for signing), CodePipeline\/CodeBuild, and admission controls in EKS (often via policy engines)<\/li>\n<li><strong>Azure<\/strong>: ACR + Defender for Cloud scanning, Azure Policy for Kubernetes, GitHub Advanced Security, and signing patterns (varies)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source \/ self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Sigstore\/cosign<\/strong> for signing container images<\/li>\n<li><strong>in-toto<\/strong> attestations<\/li>\n<li><strong>Tekton Chains<\/strong> for provenance<\/li>\n<li><strong>Harbor<\/strong> as a registry with policy\/scanning<\/li>\n<li><strong>OPA Gatekeeper<\/strong> for Kubernetes policy (configuration-focused; not image provenance by itself)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Google Cloud Software supply chain security (Cloud Build + Artifact Registry + Container Analysis + Binary Authorization + KMS + GKE)<\/td>\n<td>Teams building on Google Cloud, especially GKE<\/td>\n<td>Strong managed integration, IAM\/audit logging, deploy-time enforcement<\/td>\n<td>Multi-service complexity; requires careful design and rollout<\/td>\n<td>You want managed CI\/artifacts + enforceable deploy-time controls in Google Cloud<\/td>\n<\/tr>\n<tr>\n<td>Google Cloud + third-party scanner\/signing tools<\/td>\n<td>Orgs with existing security tooling<\/td>\n<td>Best-of-breed scanning policies, existing enterprise workflows<\/td>\n<td>Integration effort; inconsistent UX<\/td>\n<td>You already standardized on a security vendor and need Google Cloud runtime integration<\/td>\n<\/tr>\n<tr>\n<td>Kubernetes-only (OPA\/Gatekeeper\/Policy Controller)<\/td>\n<td>Config governance in clusters<\/td>\n<td>Great for Kubernetes policy (RBAC, pod security, allowed registries)<\/td>\n<td>Doesn\u2019t inherently prove build provenance or signed artifact trust<\/td>\n<td>You mainly need config guardrails; complement with image signing\/attestations<\/td>\n<\/tr>\n<tr>\n<td>AWS native equivalents<\/td>\n<td>Workloads on AWS<\/td>\n<td>Deep AWS service integration<\/td>\n<td>Different primitives and IAM model<\/td>\n<td>Your primary platform is AWS<\/td>\n<\/tr>\n<tr>\n<td>Azure native equivalents<\/td>\n<td>Workloads on Azure<\/td>\n<td>Integration with GitHub ecosystem and Azure governance<\/td>\n<td>Different primitives and coverage<\/td>\n<td>Your primary platform is Azure<\/td>\n<\/tr>\n<tr>\n<td>Self-managed (Harbor + cosign + CI of choice)<\/td>\n<td>Air-gapped or high-control environments<\/td>\n<td>Full control; portable across clouds<\/td>\n<td>High ops overhead; patching and scaling burden<\/td>\n<td>You need portability\/air-gap, and can operate the stack reliably<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example (regulated financial services)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multiple dev teams deploy microservices to GKE. Audit requires proof that production runs only approved builds, and security needs visibility into vulnerabilities.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Cloud Build in a dedicated \u201cbuild\u201d project using hardened CI templates<\/li>\n<li>Artifact Registry in a central \u201cartifacts\u201d project, regional to clusters<\/li>\n<li>Container Analysis enabled for vulnerability visibility<\/li>\n<li>Binary Authorization enforced on production clusters with:<ul>\n<li>attestor A: \u201cbuilt by CI\u201d<\/li>\n<li>attestor B: \u201cpassed integration tests\u201d<\/li>\n<li>attestor C: \u201cchange approved\u201d<\/li>\n<\/ul>\n<\/li>\n<li>Cloud KMS keys per environment with strict IAM and audit logging<\/li>\n<li>Cloud Logging and SCC (tier per policy) to centralize findings and alerts<\/li>\n<li><strong>Why this service was chosen:<\/strong> Managed services reduce operational burden, and Binary Authorization provides strong deploy-time controls integrated with GKE.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced risk of unauthorized\/untested images reaching production<\/li>\n<li>Faster audits with concrete evidence (attestations, logs)<\/li>\n<li>Improved vulnerability remediation prioritization<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (SaaS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Small team moves fast; they want simple guardrails so production isn\u2019t accidentally deployed from local builds or unreviewed images.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Cloud Build builds on merge to main and pushes to Artifact Registry<\/li>\n<li>A single KMS key and one Binary Authorization attestor for \u201cCI-built\u201d<\/li>\n<li>Production GKE cluster enforces that only attested digests can run<\/li>\n<li>Basic vulnerability review from Artifact Registry scanning (with manual triage at first)<\/li>\n<li><strong>Why this service was chosen:<\/strong> Low operational overhead; strong baseline security without running extra infrastructure.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Clear separation between developer experiments and production<\/li>\n<li>Reduced chance of accidental or malicious image deployment<\/li>\n<li>Gradual path to stronger controls (additional attestations later)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is \u201cSoftware supply chain security\u201d a single Google Cloud product?<\/strong><br\/>\nNo\u2014commonly it\u2019s a solution area implemented using multiple Google Cloud services (Cloud Build, Artifact Registry, Binary Authorization, Container Analysis, Cloud KMS, and often GKE). Verify the latest Google Cloud product packaging in official docs.<\/p>\n\n\n\n<p>2) <strong>Do I need GKE to use Software supply chain security?<\/strong><br\/>\nYou can secure build and artifact storage without GKE, but <strong>deploy-time enforcement<\/strong> with Binary Authorization is most commonly demonstrated with GKE. Verify other supported runtimes in Binary Authorization docs.<\/p>\n\n\n\n<p>3) <strong>What is Binary Authorization actually enforcing?<\/strong><br\/>\nBinary Authorization evaluates a policy at deploy\/admission time and allows or denies deploying container images based on rules such as required attestations.<\/p>\n\n\n\n<p>4) <strong>What is an attestation?<\/strong><br\/>\nAn attestation is a signed statement that an artifact (usually identified by digest) meets a requirement (built by CI, passed tests, approved, etc.).<\/p>\n\n\n\n<p>5) <strong>Why deploy by digest instead of tag?<\/strong><br\/>\nTags are mutable. A digest is immutable, making it far safer for policy enforcement and traceability.<\/p>\n\n\n\n<p>6) <strong>Where do vulnerability scan results show up?<\/strong><br\/>\nTypically in Artifact Registry (image details) and via Container Analysis metadata. Exact UI\/CLI paths can vary\u2014verify in docs for your artifact type and configuration.<\/p>\n\n\n\n<p>7) <strong>Does Cloud Build automatically generate SLSA provenance?<\/strong><br\/>\nCloud Build has features related to build provenance, and Google Cloud references SLSA concepts, but exact capabilities and how to enable\/export them can change. Verify the current Cloud Build provenance\/SLSA documentation.<\/p>\n\n\n\n<p>8) <strong>Can I use cosign\/Sigstore instead of Binary Authorization attestations?<\/strong><br\/>\nYou can use cosign for image signing, but enforcement on Google Cloud depends on the runtime and policy system. Binary Authorization has its own attestation model. Some organizations use both patterns; verify best integration for your target runtime.<\/p>\n\n\n\n<p>9) <strong>How do I handle emergency deployments if signing is down?<\/strong><br\/>\nPlan a break-glass process: a temporary policy change with approvals, time-boxed and audited, plus a post-incident review.<\/p>\n\n\n\n<p>10) <strong>Who should be allowed to sign attestations?<\/strong><br\/>\nIdeally, only your controlled CI identity (or a small release engineering group). Do not allow broad developer signing in production.<\/p>\n\n\n\n<p>11) <strong>What\u2019s the difference between vulnerability scanning and admission enforcement?<\/strong><br\/>\nScanning provides visibility and findings; admission enforcement blocks non-compliant deploys. Many teams start with scanning and later add enforcement.<\/p>\n\n\n\n<p>12) <strong>Can I require multiple attestations (build + tests + approval)?<\/strong><br\/>\nYes, that\u2019s a common pattern. Policy design determines how many attestations and which attestors are required (verify policy schema in docs).<\/p>\n\n\n\n<p>13) <strong>How do I rotate signing keys safely?<\/strong><br\/>\nAdd a new key version\/public key to the attestor first, sign new artifacts with the new key, then retire old keys after old artifacts age out.<\/p>\n\n\n\n<p>14) <strong>How do I prevent developers from bypassing the system by pushing directly to the registry?<\/strong><br\/>\nRestrict Artifact Registry write permissions to CI service accounts, enforce Binary Authorization in clusters, and monitor registry audit logs.<\/p>\n\n\n\n<p>15) <strong>What are the first steps for a beginner team?<\/strong><br\/>\nStart with: Artifact Registry + Cloud Build + basic vulnerability visibility, then add Binary Authorization enforcement in staging, then production.<\/p>\n\n\n\n<p>16) <strong>Is this only for containers?<\/strong><br\/>\nMost Google Cloud-native enforcement patterns focus on containers and Kubernetes. For other artifact types, you can still apply provenance, signing, and storage controls, but enforcement mechanisms differ.<\/p>\n\n\n\n<p>17) <strong>How does this relate to DevSecOps?<\/strong><br\/>\nSoftware supply chain security is a core DevSecOps practice: integrating security controls into CI\/CD with automation, policy, and auditability.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Software supply chain security<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official overview \/ landing<\/td>\n<td>Google Cloud Security documentation<\/td>\n<td>Entry point to security concepts and services on Google Cloud: https:\/\/cloud.google.com\/security<\/td>\n<\/tr>\n<tr>\n<td>Official docs<\/td>\n<td>Binary Authorization documentation<\/td>\n<td>Deploy-time enforcement model, policies, attestors, and GKE integration: https:\/\/cloud.google.com\/binary-authorization\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official docs<\/td>\n<td>Artifact Registry documentation<\/td>\n<td>Repos, IAM, formats, scanning basics: https:\/\/cloud.google.com\/artifact-registry\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official docs<\/td>\n<td>Cloud Build documentation<\/td>\n<td>CI builds, triggers, build config patterns: https:\/\/cloud.google.com\/build\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official docs<\/td>\n<td>Container Analysis documentation<\/td>\n<td>Artifact metadata model and vulnerability occurrences: https:\/\/cloud.google.com\/container-analysis\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official docs<\/td>\n<td>Cloud KMS documentation<\/td>\n<td>Key management for signing and rotation: https:\/\/cloud.google.com\/kms\/docs<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>Cloud Build pricing<\/td>\n<td>Understand build cost drivers: https:\/\/cloud.google.com\/build\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>Artifact Registry pricing<\/td>\n<td>Storage and network costs: https:\/\/cloud.google.com\/artifact-registry\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>GKE pricing<\/td>\n<td>Cluster\/node cost planning: https:\/\/cloud.google.com\/kubernetes-engine\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Pricing<\/td>\n<td>Cloud KMS pricing<\/td>\n<td>Key version and operation costs: https:\/\/cloud.google.com\/kms\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Official best practices<\/td>\n<td>Google Cloud Architecture Center<\/td>\n<td>Reference architectures and best practices (search for supply chain, CI\/CD, GKE security): https:\/\/cloud.google.com\/architecture<\/td>\n<\/tr>\n<tr>\n<td>Standards reference<\/td>\n<td>SLSA framework<\/td>\n<td>Industry framework to structure supply chain maturity: https:\/\/slsa.dev\/<\/td>\n<\/tr>\n<tr>\n<td>Videos<\/td>\n<td>Google Cloud Tech YouTube<\/td>\n<td>Product walkthroughs and demos (search Binary Authorization, Artifact Registry, Cloud Build): https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<\/tr>\n<tr>\n<td>Hands-on labs<\/td>\n<td>Google Cloud Skills Boost catalog<\/td>\n<td>Official labs (search for Binary Authorization, Cloud Build, Artifact Registry): https:\/\/www.cloudskillsboost.google\/<\/td>\n<\/tr>\n<tr>\n<td>Samples<\/td>\n<td>Cloud Build samples (GitHub)<\/td>\n<td>Real build config examples (verify official repo references from docs): https:\/\/github.com\/GoogleCloudPlatform\/cloud-build-samples<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>CI\/CD, DevSecOps practices, Kubernetes, cloud operations<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>DevOps beginners to intermediates<\/td>\n<td>SCM, CI\/CD fundamentals, DevOps tooling<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud engineers and ops teams<\/td>\n<td>Cloud operations, monitoring, automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and reliability-focused engineers<\/td>\n<td>SRE practices, reliability engineering, incident management<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, automation, monitoring analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps \/ cloud training content (verify offerings)<\/td>\n<td>Beginners to practitioners<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training (verify course list)<\/td>\n<td>DevOps engineers, students<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps freelancing\/training platform (verify services)<\/td>\n<td>Teams seeking short-term help\/training<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources (verify services)<\/td>\n<td>Ops and DevOps teams<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify offerings)<\/td>\n<td>Platform engineering, CI\/CD, cloud architecture<\/td>\n<td>Designing CI\/CD guardrails, registry migration planning, GKE operational setup<\/td>\n<td>https:\/\/www.cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps enablement and consulting (verify offerings)<\/td>\n<td>Training-led implementations, DevOps transformation<\/td>\n<td>Setting up Cloud Build pipelines, introducing Binary Authorization policies, operational runbooks<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services (verify offerings)<\/td>\n<td>CI\/CD, automation, cloud operations<\/td>\n<td>Standardizing build templates, integrating scanning gates, building secure deployment patterns<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<p>To be effective with Google Cloud Software supply chain security patterns, learn:\n&#8211; Google Cloud fundamentals: projects, IAM, service accounts, audit logs\n&#8211; Container basics: Dockerfiles, registries, image digests vs tags\n&#8211; CI\/CD basics: pipelines, artifacts, environment promotion\n&#8211; Kubernetes basics (especially if using GKE): deployments, services, namespaces\n&#8211; Security fundamentals: least privilege, key management, threat modeling<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced GKE security:<\/li>\n<li>workload identity patterns<\/li>\n<li>network policies and segmentation<\/li>\n<li>policy-as-code for Kubernetes config<\/li>\n<li>Advanced CI security:<\/li>\n<li>hermetic builds<\/li>\n<li>dependency pinning and lockfiles<\/li>\n<li>reproducible builds and provenance frameworks (SLSA)<\/li>\n<li>Vulnerability management program:<\/li>\n<li>SLAs by severity<\/li>\n<li>exception workflows<\/li>\n<li>patch automation<\/li>\n<li>Organization-wide governance:<\/li>\n<li>org policies, folder\/project design<\/li>\n<li>centralized logging and SIEM export<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DevOps Engineer \/ Senior DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Cloud Security Engineer<\/li>\n<li>Application Security Engineer (AppSec)<\/li>\n<li>Cloud Architect \/ Solutions Architect<\/li>\n<li>Release Engineer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>There is no single \u201cSoftware supply chain security\u201d certification from Google Cloud. Relevant Google Cloud certifications commonly include:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud DevOps Engineer\n&#8211; Professional Cloud Security Engineer\n&#8211; Professional Cloud Architect<\/p>\n\n\n\n<p>Verify current certifications and exam guides:\nhttps:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a multi-attestor model: \u201cbuilt\u201d, \u201ctested\u201d, \u201capproved\u201d<\/li>\n<li>Implement artifact promotion with the same digest across envs<\/li>\n<li>Create a policy exception workflow with time-bound exemptions<\/li>\n<li>Add SBOM generation in CI (tooling choice varies; verify best fit)<\/li>\n<li>Centralize logs and create alerts for Binary Authorization denials<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact<\/strong>: A build output such as a container image or package.<\/li>\n<li><strong>Artifact Registry<\/strong>: Google Cloud service for storing and managing artifacts (containers and packages).<\/li>\n<li><strong>Attestation<\/strong>: A signed statement about an artifact (for example, \u201cthis digest was built by CI\u201d).<\/li>\n<li><strong>Attestor<\/strong>: An entity in Binary Authorization that verifies attestations using trusted public keys.<\/li>\n<li><strong>Binary Authorization<\/strong>: Google Cloud deploy-time policy enforcement for container images on supported runtimes (commonly GKE).<\/li>\n<li><strong>Build provenance<\/strong>: Metadata describing how an artifact was built (inputs, process, identity). Verify current Cloud Build provenance features.<\/li>\n<li><strong>Container Analysis<\/strong>: Google Cloud service for storing and retrieving metadata (such as vulnerabilities) about container images and other artifacts.<\/li>\n<li><strong>CVE<\/strong>: Common Vulnerabilities and Exposures identifier for a known vulnerability.<\/li>\n<li><strong>Digest<\/strong>: Immutable cryptographic hash identifying a specific image content (e.g., <code>sha256:...<\/code>).<\/li>\n<li><strong>GKE<\/strong>: Google Kubernetes Engine, managed Kubernetes on Google Cloud.<\/li>\n<li><strong>IAM<\/strong>: Identity and Access Management in Google Cloud.<\/li>\n<li><strong>KMS<\/strong>: Key Management Service; Google Cloud service for cryptographic keys.<\/li>\n<li><strong>Least privilege<\/strong>: Security principle of granting only the permissions needed for a task.<\/li>\n<li><strong>SLSA<\/strong>: Supply-chain Levels for Software Artifacts, a maturity framework for supply chain integrity.<\/li>\n<li><strong>Tag<\/strong>: A mutable label for an image (e.g., <code>:v1<\/code>, <code>:latest<\/code>), not a guarantee of immutability.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Software supply chain security in <strong>Google Cloud<\/strong> (within <strong>Application development<\/strong>) is an architectural approach implemented with multiple managed services\u2014most commonly <strong>Cloud Build<\/strong>, <strong>Artifact Registry<\/strong>, <strong>Container Analysis<\/strong>, <strong>Binary Authorization<\/strong>, <strong>Cloud KMS<\/strong>, and <strong>GKE<\/strong>\u2014to ensure that only trusted, traceable, and policy-compliant artifacts reach runtime.<\/p>\n\n\n\n<p>It matters because modern software is built from many dependencies and automated pipelines that attackers increasingly target. The key security value comes from combining:\n&#8211; <strong>trusted builds and audit logs<\/strong>\n&#8211; <strong>centralized artifact storage and scanning<\/strong>\n&#8211; <strong>cryptographic attestations<\/strong>\n&#8211; <strong>deploy-time enforcement<\/strong><\/p>\n\n\n\n<p>Cost is driven mainly by <strong>GKE<\/strong>, <strong>Cloud Build usage<\/strong>, <strong>Artifact Registry storage\/egress<\/strong>, <strong>KMS operations<\/strong>, and <strong>logging retention<\/strong>. Security success depends on <strong>least-privilege IAM<\/strong>, digest-based deployments, protected signing keys, and a staged rollout from \u201cobserve\u201d to \u201cenforce.\u201d<\/p>\n\n\n\n<p>Next step: review the official docs for Binary Authorization and Artifact Registry, then expand the lab into a multi-environment promotion pipeline with additional attestations and vulnerability gating aligned to your organization\u2019s risk tolerance.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Application development<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54,51],"tags":[],"class_list":["post-611","post","type-post","status-publish","format-standard","hentry","category-application-development","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/611","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=611"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/611\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=611"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=611"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=611"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}