Secure CI/CD Pipelines and Supply Chain Integrity

Governance of continuous integration and continuous delivery (CI/CD) architectures means defining compliance rules as code and proving pipelines follow them over time. Cloud Logging (opens in a new tab) records pipeline activity and policy decisions as an auditable trail, while Policy-as-Code engines check infrastructure as code (IaC) against guardrails before and after deployment. Prevention at check-in blocks misconfigurations early, and detection in production catches drift when policies, images, or workloads change later.

1.1Enforce Infrastructure Guardrails with Policy-as-Code

Policy-as-Code for CI/CD infrastructure is the practice of writing compliance rules as machine-readable files and automatically checking IaC against them in the pipeline. Open Policy Agent (OPA) is the general policy engine for this pattern, and Policy Controller (opens in a new tab) is its Kubernetes admission enforcement point that applies constraints to clusters and blocks noncompliant resources. When declarative IaC from tools such as Terraform, Config Controller, Jenkins, and Cloud Build flows through these checks, every change gets a repeatable known-good state and automatic validation before it is applied.

Central Google Cloud guardrails surround the pipeline infrastructure itself. Identity and Access Management (IAM) (opens in a new tab) authorizes who can act on specific resources, while the Organization Policy Service centrally restricts how resources can be configured across folders and projects. VPC Service Controls (opens in a new tab) adds defense in depth by creating service perimeters around Google Cloud services, and Privileged Access Manager with principal access boundary policies further limits privileged use. Tags with IAM and IAM Conditions extend the same model with attribute-based access control, so a tag attached to pipeline projects carries its own access definition.

Organization policies commonly applied to CI/CD environments include:

• Limit resource sharing based on domain to prevent cross-organization access.
• Limit the use of service accounts to control which identities pipelines can use.
• Restrict the physical location of newly created resources to meet residency requirements.

1.2Block Untrusted Images Before Deployment

Binary Authorization (opens in a new tab) is the pre-deployment policy gate that allows only trusted container images to deploy to supported platforms. The Binary Authorization policy maintains an exempt image list and can block all other images, so only images from trusted registries reach Google Kubernetes Engine (GKE), Cloud Run, and GKE Enterprise. The policy can also require attestations, which are signed digital documents stating that a required process completed successfully for that image.

Attestations commonly assert that an image was built by Cloud Build or that vulnerability checks found no vulnerabilities above a specified severity. Images with specific non-applicable findings can be placed on an allowlist so they do not fail the severity gate. Because the deployment pipeline depends on the attestor and the registry, a missing or invalid attestation stops promotion from development to test to production and preserves supply-chain integrity.

1.3Detect Post-Deploy Drift with Continuous Validation

Continuous validation extends Binary Authorization policy validation to the post-deploy environment throughout the Pod lifecycle. Continuous validation for already-running Pods does not block those Pods but regularly writes policy conformance results to Cloud Logging. That log stream becomes the audit record that shows which Pods comply and which violate the current policy at each evaluation interval.

Continuous validation is especially important when the desired state changes after deployment. If an administrator tightens the Binary Authorization policy after containers are running, continuous validation logs the now-violating Pods. It also logs violations for Pods admitted through dry run mode or through breakglass emergency bypass, so exceptional access remains visible. The flow therefore runs from the admission controller to the running Pod to Cloud Logging, where drift can be queried, alerted on, and retained for compliance reporting.

1.4Monitor Workload Configuration Against Best Practices

The GKE security posture dashboard is the fleet-level monitor that checks deployed workloads for configuration concerns without manual review across clusters. Automatic workload configuration scanning compares each workload against industry best practices such as the Pod Security Standards, rates the severity of discovered issues, and returns actionable recommendations plus logs. Those findings flow to Cloud Logging to create an auditable trail of concerns for reporting and observability.

Cloud Run provides a parallel security panel for services that shows software supply chain signals such as Supply-chain Levels for Software Artifacts (SLSA) build-level compliance, build provenance, and vulnerabilities in running services. Together, admission policy and posture scanning divide responsibility: Binary Authorization proves where an image came from, while posture dashboards prove how securely the workload is configured where it runs.

The three controls compose into layered governance because each sees a different change: admission sees new deployments, continuous validation sees policy changes and bypasses, and configuration scanning sees workload misconfigurations that image signing alone cannot detect.

1.5Gate Promotions and Audit Pipeline Operations

Cloud Deploy is the fully managed delivery service that adds human oversight through gated deployments for GKE targets. A Cloud Deploy release pipeline defines promotion targets for development, test, and production, and the gated deployment feature requires explicit approval before promotion to a target proceeds. Approvals prevent unauthorized users from changing application environments and create visibility into who authorized each promotion.

CI/CD tooling itself must be treated like a production system with monitoring and audited emergency access. Dashboards and alerting on Cloud Logging and Cloud Monitoring data track pipeline health, while Service Level Indicators (SLIs) and Service Level Objectives (SLOs) can track build and deployment stage latency. When normal controls must be bypassed during a disaster, breakglass procedures apply under three practices: maintain a clear escalation plan that states when emergency access is allowed, ensure multiple people hold critical configuration and secrets, and develop automated auditing so every use records when it occurred and who used it.

Software supply chain integrity is the assurance that only verified source code, dependencies, and builds reach production. In Google Cloud, that assurance forms a connected chain: Cloud Build (opens in a new tab) generates cryptographic proof of how an image was built, Artifact Registry centralizes storage, Artifact Analysis continuously scans artifacts, and Binary Authorization blocks deployment unless required proofs are present. Data flows from source to build to registry to cluster, and each handoff adds verifiable state before the next step is allowed.

2.1Centralize Artifacts in Artifact Registry

Artifact Registry (opens in a new tab) is a universal package manager for build artifacts and dependencies that gives centralized visibility and control over the software supply. Centralization lets teams apply consistent access control, Virtual Private Cloud (VPC) Service Controls perimeters, and organization policies to the code that flows into builds and deployments. Traffic flows from external sources into controlled repositories and then to builds, so every dependency has a scannable entry point before production.

Two repository types reduce risk from external dependencies:

• Remote repositories cache artifacts from preset external sources such as Docker Hub, Maven Central, Python Package Index (PyPI), Debian, CentOS, and user-defined sources, which reduces download time, improves availability, and enables vulnerability scanning when scanning is enabled.
• Virtual repositories consolidate repositories of the same format behind a single endpoint and control search order across upstream repositories, so private packages can be prioritized to reduce dependency confusion attacks.
• Assured Open Source Software packages complement private artifacts by providing open source packages built in Google secure pipelines and regularly scanned, analyzed, and tested for vulnerabilities.

2.2Automate Continuous Vulnerability Scanning with Artifact Analysis

Artifact Analysis (opens in a new tab) is the service that proactively detects vulnerabilities in artifacts stored in Artifact Registry. Scanning starts when a new container image is uploaded, when Artifact Analysis extracts information about system packages and language packages in the container, and it supports both on-demand and automated scanning modes. Teams can also generate a software bill of materials (SBOM) to list dependencies and upload Vulnerability Exploitability eXchange (VEX) statements to record whether a vulnerability is actually exploitable.

Continuous monitoring keeps results current after the initial scan. When Artifact Analysis receives new and updated information from vulnerability sources, it updates the metadata of scanned images, creates new vulnerability occurrences for new findings, and deletes occurrences that are no longer valid. Because monitoring applies to metadata already stored in Artifact Registry, an image that was clean at build time can be flagged later without rebuilding or rescanning manually.

2.3Generate Cryptographic Build Provenance with Cloud Build

Cloud Build provenance is verifiable metadata about a build that links an output digest back to its inputs and process. Cloud Build runs builds on Google Cloud infrastructure in isolated and ephemeral build environments with granular IAM permissions and VPC Service Controls. Isolation means each build runs in a fresh environment that does not persist state to the next build, which limits tampering from prior steps.

For container images, Cloud Build supports Supply-chain Levels for Software Artifacts (SLSA) (opens in a new tab) Level 3 builds and generates authenticated and non-falsifiable build provenance. Provenance for built applications includes the digests of built images, input source locations, build toolchain, build steps, and build duration. Security insights dashboards expose the SLSA build level, vulnerabilities in build artifacts, and the provenance itself, so operators can confirm what source produced which digest before promotion.

2.4Restrict GKE Deployments with Binary Authorization

Binary Authorization (opens in a new tab) is deployment-time policy enforcement for GKE and Cloud Run that allows only verified container images to run. The service uses configurable signatures attached to container images, called attestations, that validate an image at deployment time. When a Pod requests an image, Binary Authorization checks for required attestations before the container is admitted, so compromised or unreviewed images are blocked even if they exist in the registry.

A Binary Authorization policy can require different proofs depending on environment and risk:

• Verify that a specific build system or continuous integration (CI) pipeline created the container image.
• Validate that the container image complies with a vulnerability signing policy based on Artifact Analysis results.
• Verify that the container image passed promotion criteria for the next environment, such as from development to quality assurance (QA).

By chaining these checks, only trusted code runs on target platforms, and the same policy framework extends across development, test, and production so each environment deploys only artifacts verified for that stage.

2.5How Scanning, Provenance, and Enforcement Connect

The integrity chain connects storage, build evidence, and deployment control into one ordered flow. The chain works because scanning without provenance cannot prove how an image was built, and provenance without enforcement cannot stop an unverified image from running. Choose this chain when deployments must prove origin and security posture, not just correct functionality.

Secure build pipeline execution means a compromised pipeline or build step cannot read data it does not need, write where it should not, or use the network to steal data. Cloud Build (opens in a new tab) provides this isolation through granular IAM permissions, VPC Service Controls perimeters, and isolated and ephemeral build environments. Together these controls enforce least privilege and network isolation while preserving verifiable integrity through SLSA Level 3 builds and build provenance.

3.1Least-Privilege IAM for Build Service Accounts

Least-privilege IAM for build pipelines means each pipeline identity receives only the minimum permissions needed to read inputs, run builds, and write outputs. Cloud Build service accounts should use granular IAM roles scoped to individual resources rather than project-level grants, and dedicated service accounts should be used per pipeline, stage, or environment. Over-granting commonly happens when a pipeline is granted Cloud Storage access at the project level and can therefore access all buckets when one bucket would suffice, or when it receives full Cloud Storage access when only permission to create buckets is required.

Limiting scope reduces blast radius if a pipeline is compromised. The deployment pipeline depends on the resources it can reach, so restrict that dependency to a small set:

• Grant deployment pipelines access to individual resources instead of granting access on the project level.
• Avoid granting access to resources across multiple Google Cloud projects.
• Split deployment pipelines into multiple stages if they need multiple projects or environments, then secure each stage individually.

For sensitive operations, further narrow the grant with IAM Conditions for conditional access and principal access boundary policies that cap what a service account can reach. Store sensitive credentials and key material in Secret Manager (opens in a new tab) and allow the build service account to access only the specific secrets required for that build. Pipelines that touch confidential data or cryptographic key material require the strictest read, write, and egress limits.

3.2Network Isolation with VPC Service Controls and Egress Control

Network isolation for build pipelines means build traffic cannot flow from the build environment to unauthorized storage, APIs, or the internet. VPC Service Controls (opens in a new tab) creates a service perimeter around selected Google Cloud projects, resources, and APIs, so code running inside the perimeter cannot call APIs or reach resources outside the allowed set. This boundary sits between the build and deployment environment on the inside and external networks and unapproved resources on the outside.

Two exfiltration paths drive egress design:

To remove data, an attacker needs both access and a transfer path, so reduce both. Revoke write access to resources the pipeline does not need, even if those resources contain no confidential data, because any writable location can serve as an exfiltration destination. Block internet access or restrict connections to an allow-listed set of network locations, which is particularly important for pipelines with access to confidential data or key material.

3.3Confidentiality and Integrity Flow Rules for Pipelines

Confidentiality and integrity rules for pipelines define which direction data is allowed to flow between the pipeline and the resources it touches. To set the required level, first determine the data, applications, and resources the pipeline needs to access and categorize them, then use the highest confidentiality or integrity category found as the initial category. An exception applies when a pipeline creates resources that will later hold highly confidential information but is restricted so it can create but cannot read those resources; then a lower confidentiality category can be sufficient.

The Bell-LaPadula model governs confidentiality and the Biba model governs integrity. Under Bell-LaPadula, a deployment pipeline must not consume input artifacts of higher confidentiality and must not write data to a resource of lower confidentiality, which keeps secrets from flowing down to less-trusted places. Under Biba, a deployment pipeline must not consume input artifacts of lower integrity and must not write data to a resource of higher integrity, which keeps untrusted code from flowing up into more-trusted systems. Protecting integrity therefore requires protecting the deployment pipeline and its configuration, the underlying infrastructure including CI/CD software, tools such as Terraform, kubectl, or Docker, and the operating system, and all inputs consumed by the pipeline.

Key Facts

• Binary Authorization blocks noncompliant container images at deploy time unless the image is exempt or has required attestations, while continuous validation only logs violations for already-running Pods to Cloud Logging.
• Artifact Registry centralizes artifacts with remote repositories that cache external sources and virtual repositories that prioritize private packages to reduce dependency confusion.
• Cloud Build supports Supply-chain Levels for Software Artifacts (SLSA) Level 3 builds that generate non-falsifiable build provenance linking image digests to source, toolchain, steps, and duration.
• VPC Service Controls creates a service perimeter around projects, resources, and APIs so compromised build code cannot reach unauthorized resources, while direct exfiltration is blocked by revoking unneeded access and restricting internet egress.