- Google Cloud's threat intelligence team says attackers now target build pipelines, security tools, developer laptops and AI coding agents, rather than flaws in shipped code.
- Google warns attackers plant malicious code in open-source MCP packages so AI coding agents run it as trusted, and also tamper with GitHub Actions caches, tokens and tags.
- Google recommends short-lived GitHub App tokens (1 hour max), a 7-day cooldown on new packages, pinned images and actions, and human review of AI-written code; ask your engineers if these are in place.
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, individual developer laptops and code editors become entry points: attackers use targeted phishing, fake browser or IDE extensions, or dependencies with names close to legitimate ones to lift private keys, tokens, and active login sessions straight from an engineer's machine. Third, and the most recent development, attackers no longer just steal static passwords and tokens — they interfere with the build process directly, planting poisoned data in GitHub Actions caches, extracting OIDC tokens meant to authenticate workflows, and altering what a mutable action tag actually points to, so a tampered package can still pass as cryptographically verified.
AI Coding Tools Now Sit Inside the Blast Radius
Google's guidance calls out a risk specific to AI adoption: attackers are planting malicious code inside open-source Model Context Protocol (MCP) packages, then getting AI coding agents to execute it as if it were trusted instructions. Google's response is a short list of controls: limit which LLMs and AI agents engineers can use for vulnerability review before code merges, keep local .env credential files out of any folder an AI agent can access, and require a person to check AI-written code before it is committed to 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.
On the package side, Google recommends holding every newly published open-source package version back before it becomes installable in internal builds, giving the community time to catch and pull malicious releases before they reach a production pipeline.
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.
