Google Cloud Threat Intel: CI/CD Pipelines Are the New Attack Surface

The Target Has Moved Up the Pipeline

Google Cloud's threat intelligence team says the software supply chain attack surface has shifted. Rather than hunting for flaws in shipped code, sophisticated actors are now going after the machinery that builds and ships it: trusted security scanners, utility libraries, AI developer tools, and the CI/CD pipelines that run with elevated privileges. For any organization that ships software, that reframes the budget conversation from 'patch the app' to 'harden the factory.'

Three Tactics Bypass Traditional Controls

Google identifies three specific patterns. First, attackers compromise trusted security and programming tools to exploit the elevated privileges those tools already hold inside build pipelines. Second, they go after developer workstations and IDEs directly, using tailored social engineering, malicious extensions, or typosquatted local dependencies to pull private cryptographic keys, API tokens, and live session credentials off the machine. Third — and newest — they have moved past stealing static credentials into manipulating the pipeline itself: GitHub Actions cache poisoning, OpenID Connect (OIDC) token extraction, and subversion of mutable action tags, techniques that let a compromised package still carry legitimate cryptographic provenance.

AI Coding Tools Now Sit Inside the Blast Radius

The guidance flags a newer wrinkle directly tied to AI adoption: threat actors have begun inserting malicious code into open-source Model Context Protocol (MCP) packages and tricking AI coding agents into acting on it. Google's recommended countermeasure is narrow and specific — restrict engineering teams to approved LLMs and AI agents for pre-merge vulnerability analysis, exclude local .env files from any workspace an AI agent can read, and keep a human in the loop verifying AI-generated code before it reaches a repository. In other words, the AI tooling meant to speed up engineering is itself now a credential-exposure and code-integrity risk that needs the same governance as any other privileged system.

The Fixes Are Concrete Configuration Changes

Google's blueprint is unusually specific about what 'harden the pipeline' means in practice. For automated CI/CD and third-party integrations, it recommends replacing long-lived service-account personal access tokens with GitHub Apps, which issue short-lived, tightly scoped tokens.

Other specifics in the guidance: pin container images by cryptographic digest rather than mutable tag, pin third-party GitHub Actions to a full commit hash, prohibit SemVer ranges (carets, tildes, wildcards) in favor of exact version pins backed by verified lockfiles, and block unverified 'curl to bash' installs in favor of vendor containers invoked by SHA-256 digest.

What to Ask Your Engineering Team

This is a checklist problem, not an awareness problem. Budget-holders should ask: do our CI/CD integrations still run on long-lived service-account tokens, or have we moved to short-lived GitHub App tokens with an enforced TTL? Are our container images and third-party actions pinned to immutable digests and commit hashes, or can an upstream party silently swap what a trusted tag points to? Do we enforce a release-age cooldown on new open-source package versions before they can enter a build, and do we generate an SBOM with SLSA provenance checks on what we ship? And specifically on AI tooling: which LLMs and coding agents are approved for use against our repositories, and is a human required to sign off before AI-generated code is committed?

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Google Threat Intelligence Group.