---
url: "https://www.xcademia.com/news/google-cloud-outlines-a-multi-layered-blueprint-to-secure-code-pipelines-and-ci-cd-infrastructure"
title: "Google Cloud Outlines a Multi-Layered Blueprint to Secure Code Pipelines and CI/CD Infrastructure"
description: "Google Cloud's Mandiant team outlines a multi-layered approach to securing software supply chains, CI/CD pipelines, developer endpoints and production."
publishedAt: "2026-09-25T11:37:46.414+00:00"
updatedAt: "2026-09-25T12:26:55.426706+00:00"
type: news
category: cybersecurity
source_name: Google Cloud Blog
source_url: "https://cloud.google.com/blog/topics/threat-intelligence/hardening-code-pipelines-and-ci-cd-infrastructure"
tags:
  - "#Cybersecurity"
  - "#SoftwareSupplyChain"
  - "#CICD"
  - "#DevSecOps"
  - "#CloudSecurity"
  - "#SupplyChainSecurity"
  - "#ApplicationSecurity"
  - "#ThreatIntelligence"
---

# Google Cloud Outlines a Multi-Layered Blueprint to Secure Code Pipelines and CI/CD Infrastructure

> Google Cloud’s Mandiant team has outlined a defence-in-depth approach to software supply chain security, covering developer endpoints, repositories, dependencies, CI/CD pipelines, artifacts and production environments.

Source: **Google Cloud Blog** · 25 September 2026

Software supply chain attacks are increasingly targeting the systems developers rely on to build and deliver applications. Instead of attacking only production systems, threat actors are targeting developer workstations, IDEs, security tools, dependencies, repositories and CI/CD infrastructure.

Google Cloud’s Mandiant team outlined a comprehensive approach for hardening the software development lifecycle against these threats. The guidance focuses on continuous verification across five major areas: endpoints, code repositories, artifact management, CI/CD infrastructure and deployment environments.

The recommendations reflect a broader shift in software supply chain security. Security controls can no longer operate as isolated checkpoints. A compromised developer machine, package, build cache or pipeline identity can potentially become a path into downstream environments.

## 
Three attack patterns are becoming particularly important

According to Mandiant, recent campaigns demonstrate several techniques that organisations need to account for.

First, attackers are targeting trusted security scanners, utility libraries and AI developer tools because these systems may have elevated privileges inside build pipelines.

Second, developer workstations and IDEs are being targeted through social engineering, malicious extensions and typosquatted dependencies. These attacks can expose credentials such as personal access tokens, SSH keys, API tokens and active session information.

Third, attackers are increasingly manipulating CI/CD mechanisms themselves. Mandiant highlights techniques including GitHub Actions cache poisoning, OpenID Connect token extraction and attacks involving mutable action tags.

The result is a security problem that extends well beyond traditional vulnerability scanning.

## 
Five pillars for securing the software development lifecycle

Mandiant's approach treats the development lifecycle as a connected security system rather than a collection of independent stages.

The five major areas covered by the guidance are:

1. **Developer endpoints**
2. **Code repositories**
3. **Artifact management**
4. **CI/CD infrastructure**
5. **Deployment and runtime environments**

The objective is to introduce security verification throughout the lifecycle so that a compromise at one stage does not automatically provide unrestricted access to subsequent stages.

![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1790336171293-info1--94-.webp)

## 
1. Developer endpoints become part of the security perimeter

Developer machines have privileged access to repositories, build systems and cloud environments. That makes them an important target for attackers.

Mandiant recommends establishing a consistent security posture across local workstations and cloud-based development environments.

### Local secret scanning

Pre-commit hooks and IDE-integrated scanning can detect secrets before developers push changes into central repositories.

The guidance also recommends reducing exposure from traditional personal access tokens by moving towards more narrowly scoped credentials with limited lifetimes.

### Endpoint Detection and Response

EDR should monitor developer environments for suspicious activity, including unusual file access, unexpected process creation and unauthorised outbound connections.

Mandiant also recommends integrating endpoint compliance information with Unified Endpoint Management systems. This can allow organisations to restrict access to source-code management systems or publishing workflows when a device falls outside the required security posture.

### Standardising IDEs and extensions

Development environments can introduce third-party risk through browser integrations, IDE extensions and other software components.

The guidance recommends maintaining approved versions, restricting unverified extensions, reviewing third-party integrations and maintaining an inventory of installed software.

This approach gives security teams the ability to respond quickly if a newly discovered vulnerability affects a development extension.

## 
AI-assisted development introduces another security boundary

AI coding tools are becoming part of modern engineering workflows, but their integration also introduces new security considerations.

Mandiant recommends that engineering teams use approved LLMs and AI agents for activities such as vulnerability analysis and application security testing.

The guidance also highlights risks associated with malicious code entering open-source Model Context Protocol packages and attempts to manipulate AI coding agents.

Organisations should therefore consider what information AI systems can access.

Local `.env` files and other sensitive resources should be excluded from AI development workspaces where possible. This reduces the possibility of credentials entering an AI model's context.

Mandiant also recommends human review of AI-generated code before it is committed to repositories.

This does not eliminate the risks associated with AI-assisted development, but it establishes an additional verification layer between AI-generated output and production software.

### Developer sandboxes

Containerised development environments and dedicated virtual machines can provide another layer of isolation.

The objective is to prevent malicious dependencies or post-install scripts from accessing sensitive host resources.

Mandiant recommends restricting sensitive host-path mounts, using hardened VM images and integrating sandbox activity with centralised logging.

## 
2. Code repositories need stronger identity and change controls

Source repositories contain proprietary code and form the central record of software development.

Mandiant recommends strengthening this layer through identity controls, branch governance and continuous auditing.

### Stronger repository identity

Organisations should enforce strong authentication and consider phishing-resistant MFA such as hardware security keys or passkeys.

The guidance discusses Company Managed Users as one approach for maintaining control over organisation-owned accounts. It also notes that this model can create limitations for teams contributing to external open-source repositories, where standard accounts combined with MFA and SSO may remain necessary.

Conditional access policies can further verify device posture before allowing repository access.

### Protect the main branch

One important recommendation is a **zero direct-to-main policy**.

Under this approach, changes move through feature branches and require peer review and automated CI checks before merging.

Administrative bypasses should be restricted, while force-push activity should be controlled and monitored.

The underlying objective is straightforward: preserve a trustworthy and auditable history of changes.

## 
Credential lifecycle management is critical

Long-lived credentials create persistence opportunities for attackers.

Mandiant recommends automating credential rotation, using short-lived credentials and applying just-in-time access wherever possible.

For developer authentication, the guidance discusses moving away from static PAT-based authentication towards cryptographically verified SSH authentication backed by hardware security mechanisms.

For CI/CD integrations, Mandiant recommends GitHub Apps rather than service-account PATs, enabling short-lived and narrowly scoped access tokens.

Secrets should also be injected through appropriate platform-native secret mechanisms rather than being unnecessarily stored in environment variables or local files.

## 
Dependency security moves beyond vulnerability databases

A dependency can be vulnerable even when there is no obvious sign of compromise in the application's own source code.

Mandiant recommends pinning dependencies to exact versions instead of relying on dynamic SemVer ranges such as `^`, `~` or `*`.

Cryptographically verified lockfiles provide another layer of consistency.

The guidance also recommends avoiding unverified execution patterns such as blindly piping remote scripts into shell interpreters.

Software Composition Analysis can then be combined with reachability analysis to help identify vulnerabilities that are actually relevant to the application's execution path.

Builds should also generate an SBOM and enforce provenance checks.

## 
3. Artifact management needs continuous verification

The security of an application does not end when source code passes a build.

Third-party packages and container images become part of the software artifact chain, making artifact management another important security boundary.

### Seven-day dependency cooldown

One notable recommendation in the Mandiant guidance is a minimum **seven-day release-age cooldown** for newly published public packages.

The reasoning is that security researchers and the open-source community may identify and remove malicious packages shortly after publication. A delay can therefore create an opportunity for detection before a newly released package enters internal builds.

This is a specific recommendation from the source rather than a universal industry requirement.

### Proxies and quarantines

Mandiant recommends routing external packages and container images through centralised internal proxies where possible.

These systems can inspect incoming components before allowing them into trusted repositories.

New components can be quarantined until they pass defined security checks.

The guidance also recommends separating internal repositories from public registries to reduce dependency confusion risks.

## 
Continuous vulnerability scanning

Point-in-time scanning is not enough because the security status of an artifact can change after it has already been stored.

Mandiant recommends continuous evaluation of container images and dependencies as new vulnerabilities emerge.

Security teams can prioritise findings using reachability information and exploitation intelligence such as the CISA Known Exploited Vulnerabilities catalogue.

Vulnerability Exploitability eXchange, or VEX, statements can also help identify findings that do not apply to a particular environment.

## 
Provenance and immutable references

Knowing that software is free from known vulnerabilities is only one part of the trust equation.

Organisations also need to establish where an artifact came from and how it was produced.

Mandiant recommends cryptographically signing internally produced packages and container images and connecting those signatures to the build workflow and source commit.

Verification should occur before artifacts enter trusted environments.

The guidance also recommends using immutable artifact digests rather than mutable tags.

For example, a container reference based on an immutable SHA-256 digest cannot silently point to a different underlying artifact without changing the digest.

The same principle applies to third-party CI/CD actions, which should be referenced using full commit hashes rather than mutable version tags.

![info-2](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1790336202325-info2--96-.webp)

## 
4. CI/CD pipelines are high-value targets

CI/CD systems frequently have access to source repositories, package registries and cloud infrastructure.

That combination makes build infrastructure particularly valuable to attackers.

Mandiant recommends eliminating persistent runner environments wherever possible.

### Ephemeral runners

Single-use runners create a fresh environment for each job and are destroyed afterwards.

This limits cross-job contamination and reduces opportunities for an attacker to establish persistent access.

Self-hosted runners should also have tightly controlled outbound network access.

The guidance recommends allowing communication only with approved registries and repository APIs where practical.

### Protecting build caches

Shared caches can improve build performance, but they can also become an attack surface.

A malicious pull request could potentially introduce corrupted dependencies into a shared cache. A later build could then retrieve those components from the cache.

Mandiant recommends isolating cache access according to branch privileges and rejecting cache writes from unauthenticated forks.

## 
Least privilege should apply to CI/CD identities

The Mandiant blueprint recommends several controls for CI/CD environments:

- Use OIDC to exchange workload identities for short-lived tokens.
- Start runner permissions at a minimal or read-only level.
- Avoid automatically inheriting credentials across nested workflows.
- Restrict third-party plugins and marketplace actions.
- Separate early validation environments from release-authorised infrastructure.
- Preserve immutable branch history.
- Scan Infrastructure-as-Code before deployment.
- Restrict network and IAM boundaries between pipeline stages.

These controls are designed to limit what an attacker can do if one component of the pipeline is compromised.

## 
Security scanning should become a series of gates

Rather than relying on one final security scan, Mandiant recommends introducing different controls throughout the CI/CD process.

### Secret scanning

At the commit or pull request stage, scanners can identify API keys, passwords and SSH keys before they become part of repository history.

### SAST

Static Application Security Testing can analyse source code during pull requests and identify structural vulnerabilities before changes reach the main branch.

### SCA

Software Composition Analysis can examine dependency lockfiles during builds and identify known vulnerabilities.

### Container scanning

Container images can be inspected before they are approved for production.

### DAST

Dynamic Application Security Testing can be performed against isolated staging environments to test running applications.

### CSPM and IaC security

Cloud infrastructure configurations can be evaluated before deployment and continuously afterwards to identify issues such as excessive IAM permissions or exposed services.

## 
SBOMs become security evidence, not just inventories

A Software Bill of Materials provides a record of the components included in a software build.

Mandiant recommends generating the SBOM during the build and signing it as an attestation connected to the artifact digest.

The guidance identifies formats such as CycloneDX and SPDX.

This creates a tamper-evident record that can be mapped back to affected artifacts when a new vulnerability is discovered.

VEX statements can then help distinguish relevant findings from vulnerabilities that do not actually affect the application.

## 
5. Deployment is the final security boundary

Even strong development and CI/CD controls cannot guarantee that every attack will be prevented.

The deployment environment therefore needs its own security controls.

Mandiant recommends automated deployment guardrails that can reject containers lacking valid signatures, requesting unnecessary root privileges or originating from untrusted registries.

Workloads should use hardened base images, immutable infrastructure and read-only filesystems where appropriate.

Just-in-time access can also replace standing administrative privileges with temporary, task-specific permissions.

## 
Protecting the live production environment

Runtime security extends beyond the application itself.

The guidance covers several defensive layers:

**Web Application Firewalls:** Inspect application traffic and block common web attacks.

**API Gateways and Load Balancers:** Centralise authentication, rate limiting and request validation.

**Microsegmentation:** Restrict communication between workloads to authorised paths.

**Configuration Integrity:** Continuously compare live infrastructure with version-controlled IaC.

**CSPM and CNAPP:** Monitor cloud environments for configuration and identity risks.

**Continuous Monitoring:** Collect logs, metrics and audit events to support detection and investigation.

For AI workloads, the guidance also references runtime controls for prompt injection and jailbreak protection, including Google Model Armor.

![info-3](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1790336244399-info3--94-.webp)

## 
What this means for software engineering teams

The central message from Mandiant's guidance is that software supply chain security needs to move closer to the engineering workflow.

Security teams can no longer focus exclusively on production infrastructure while treating developer environments and build systems as trusted zones.

A compromised IDE extension, dependency, repository credential, CI/CD action or build cache can become relevant to the security of the final application.

The guidance therefore connects security controls across the entire development lifecycle:

**Developer → Repository → Dependency → Artifact → Pipeline → Deployment → Runtime**

Each stage should verify what it receives from the previous stage and limit what it can do in the next stage.

For enterprises, this could mean greater investment in ephemeral infrastructure, short-lived identities, immutable artifact references, centralised package controls, continuous scanning and policy enforcement.

It also means security engineering and platform engineering need to operate more closely together.

## 
The broader industry shift

The announcement highlights a broader industry shift toward treating the software development lifecycle itself as a security boundary.

Traditional security models often concentrated on protecting applications after deployment. Modern supply chain attacks demonstrate why the path used to create those applications also requires continuous protection.

The approach outlined by Mandiant emphasises three principles:

**Verify continuously:** Security checks should operate throughout the lifecycle rather than at a single point.

**Limit privileges:** Developer, pipeline and runtime identities should receive only the permissions they need.

**Contain compromise:** Systems should be designed so that the compromise of one component does not automatically provide unrestricted access to the rest of the environment.

This is particularly relevant as organisations adopt cloud-native development, automated CI/CD and AI-assisted coding workflows.

The source does not claim that these controls eliminate software supply chain attacks. Instead, the guidance focuses on reducing exposure, improving verification and limiting the potential spread of a compromise.

## 
Conclusion

Google Cloud's Mandiant team has presented software supply chain security as an end-to-end engineering challenge.

The recommended architecture spans developer endpoints, source repositories, dependencies, artifact registries, CI/CD runners, deployment controls and runtime infrastructure.

Key recommendations include stronger developer authentication, secret scanning, approved IDE extensions, AI development safeguards, isolated workspaces, protected branches, short-lived credentials, dependency pinning, package cooldowns, artifact quarantine, cryptographic provenance, immutable references, ephemeral CI/CD runners, security scanning gates, signed SBOMs and runtime protection.

The broader lesson is that pipeline security is not simply about adding more scanners.

It is about creating a chain of trust in which identities, source code, dependencies, build environments and deployment artifacts are continuously verified.

For organisations building software at scale, this approach can provide a structured framework for reducing the opportunities available to attackers while making compromises easier to isolate and investigate.

## Original source

https://cloud.google.com/blog/topics/threat-intelligence/hardening-code-pipelines-and-ci-cd-infrastructure

## Tags

`#Cybersecurity` · `#SoftwareSupplyChain` · `#CICD` · `#DevSecOps` · `#CloudSecurity` · `#SupplyChainSecurity` · `#ApplicationSecurity` · `#ThreatIntelligence`

---

## About this content

This Markdown news article is the citation-grade twin of [Google Cloud Outlines a Multi-Layered Blueprint to Secure Code Pipelines and CI/CD Infrastructure](https://www.xcademia.com/news/google-cloud-outlines-a-multi-layered-blueprint-to-secure-code-pipelines-and-ci-cd-infrastructure). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite.

When citing or quoting, please attribute *Xcademia* and link back to the source URL above.

- Source: https://www.xcademia.com/news/google-cloud-outlines-a-multi-layered-blueprint-to-secure-code-pipelines-and-ci-cd-infrastructure
- Publisher: Xcademia — https://www.xcademia.com
- Catalogue index: https://www.xcademia.com/llms-full.txt