GTIG and Mandiant publish a supply-chain hardening playbook aimed at CI/CD teams

Your build pipeline runs code you did not write, from repositories you do not control, with credentials that can push to production. Fine. That is the deal. On July 30, Google's Threat Intelligence Group (GTIG) and Mandiant published a joint mitigation guide for software supply chain compromise, and the interesting bit is not the threat catalog. It is how much of the fix has to happen inside your CI/CD.

What the guide is doing on your desk

The write-up, credited to Kelli Vanderlee and Stuart Carrera, opens with a lineup of recent campaigns: a compromise of the widely-used axios npm package attributed to an actor GTIG tracks as MIDNIGHT NEPTUNE, a longer sequence of typosquatted PyPI, npm and Docker Hub packages from UNC6780, and installer-tampering incidents against Notepad++ and DAEMON Tools. GTIG reports malicious open source package volume grew 1,444% from 2024 to 2025. The axios malicious versions were pulled from npm within three hours; GTIG still supported customers across at least 15 industry verticals and 13 countries.

The recommendations sit in four buckets: administrative oversight, vendor lifecycle management, security architecture and engineering controls, and continuous verification and response. That framing is useful for a CISO deck. It is a bit less useful if you are the engineer who has to change the workflow files by Friday.

Where the pipeline levers actually sit

Strip the categories away and most of the concrete advice lands in familiar places.

Identity moves first. The guide recommends replacing static, long-lived Personal Access Tokens with dedicated GitHub Apps or short-lived tokens issued via federated OIDC, capping any PATs that remain at a seven-day lifespan, and requiring hardware-backed FIDO2 keys for CLI actions against your repositories. It flags high-privilege triggers like pull_request_target as something to restrict rather than leave enabled by default. If your Actions runners are shared, GTIG wants them ephemeral: spin up, run one job, tear down.

Package ingestion is the other half. For Node.js, the guide points at npm and pnpm's minimumReleaseAge setting (at least 24 hours, or 1440 minutes) so a newly-published version cannot land in a build before anyone has looked at it. It calls for ignore-scripts=true in .npmrc to stop postinstall from doing whatever it wants, and cites npm v12's July 2026 change to disable lifecycle scripts by default. For Python, it recommends routing installs through a vetted private index rather than the public PyPI. Two platform-level guardrails from July 2026 get name-checked: Dependabot's default three-day cooldown on version updates and PyPI's 14-day file-upload immutability window.

Verification is prosaic and unglamorous. Use npm ci for immutable installs. Run OSV-Scanner in the pipeline. Verify vendor signatures. Restrict runner egress to an allowlist. Add SBOM tracking and, GTIG suggests, an "action bill of materials" inventorying every third-party GitHub Action a workflow depends on.

The uncomfortable parts

Most of this is not new. The ignore-scripts=true recommendation has been in npm's own docs for years. OIDC-federated CI credentials are supported across the major platforms and still only partly adopted. Package cooldowns were the fix everyone reached for after the historical chalk and debug hijackings, and they still catch teams flat-footed. What GTIG is really publishing here is a homework list, consolidated, with an incident roster behind it that is hard to argue with.

Two things worth calling out. The guide leans on the GitHub plus npm plus PyPI stack that most CI/CD teams live in; if your pipeline is JVM-first or Go-first, you will have to translate. And an "action bill of materials" is a nice control on paper. In practice it is another artifact your team has to generate, store, sign and actually consult during an incident. Skip it if you are not going to look at it.

How the wider toolchain answers this

The controls the guide asks for already ship, in pieces, across the ecosystem. Honest picks:

• OSV-Scanner is Google's own reference frontend to the OSV.dev vulnerability database, and it is genuinely straightforward to wire into a CI job. If you want to follow one recommendation from this guide today, this is the low-cost first step.
• Dependabot and Renovate cover the automated-updates side. Renovate is the better fit if you need cross-registry support and fine-grained cooldown policies without waiting for a platform default; Dependabot is the answer if you live entirely inside GitHub and want less to configure.
• Sigstore plus SLSA attestations answer the "verify signatures" bullet, once you have somewhere downstream that actually checks them. Generation is the easy part; verification is where deployments still quietly skip the check.
• Artifactory and Sonatype Nexus are the mainstream answers for a vetted private index. If a regulator cares about your controlled software supply chain, these have the audit story your platform team will be asked for. They are a heavier lift than any of the above.
• Chainguard Images and hardened base images address the container side of the same problem: what you pull down before a build even runs. Not a replacement for any of the above; a layer beneath.
• Buddy exposes ephemeral runners, per-pipeline OIDC credentials and per-step secret scoping as YAML you edit in one place, which is one concrete reason to consider it if the guide's identity bullets are what you are trying to close first. It is not a scanner and not a signer. It is the runner and the wiring around them.

If your priority is scanner depth or attestation policy, one of the specialist tools above is the better fit; nothing about a pipeline platform closes a CVE for you.

The bit worth remembering

Every recommendation in the GTIG guide is a control that already exists in your stack. The reason your build still runs a stolen token as root is not that the mitigations do not ship. It is that nobody enforced them. Read the list, pick two, and turn them on before the next axios.