Proactive Defense: Hardening Code Pipelines and CI/CD Infrastructure

What it is

Mandiant guidance for software and platform architects on hardening the SDLC across five pillars: endpoint, code repositories, artifact management, CI/CD and deployment. It is a control checklist, not a incident write-up. It names no CVEs and no specific campaigns, and it defers exact configuration (npm minimumReleaseAge, pip indexing) to a companion blog.

What to do

The page states these controls beyond the headline items in the summary.

Repositories and credentials

• Replace service-account PATs in pipelines with GitHub Apps, whose tokens expire after one hour. Move developers from classic PATs to fine-grained PATs with short TTLs, or to SSH backed by hardware keys (FIDO2/YubiKey or macOS Secure Enclave).
• Forbid ^, ~ and * version ranges. Require exact pins (for example 1.4.2) plus verified lockfiles.
• Block "curl to bash" installs. Use vendor containers pinned by SHA-256 digest.
• Require zero direct commits to main, no admin bypass, and restricted, monitored force-push. Review audit history for timeline tampering and dead-drop repositories.
• Keep secrets out of environment variables. Exclude .env from git and from AI agent workspaces, and inject secrets at runtime.

Artifacts

• Route all external packages and images through one internal proxy (the page names Google Artifact Registry). Hold new components in quarantine and fail builds on a bad verdict. Keep internal and public repositories separate to prevent dependency confusion.
• Verify signatures at admission, against an exact expected build identity and an immutable digest, never a tag.
• Replace long-lived registry publish tokens with short-lived tokens bound to a build workflow.
• Pin every image a build touches, including base images, sidecars and init containers. Avoid configurations that re-resolve a mutable tag on each production restart.
• Prioritise findings by reachability and the CISA KEV catalog, and suppress inapplicable ones with VEX.

CI/CD

• Use ephemeral single-use runners. For self-hosted runners, limit outbound traffic to approved registries and repository APIs.
• Against Poisoned Pipeline Execution, block unvetted pull request code from secrets and deployment-grade runners until an administrator approves.
• Isolate build caches by branch privilege and reject cache writes from unauthenticated forks. The stated risk is that a malicious pull request poisons a shared cache and a later production build runs it.
• Default runner identities to read-only or no permissions. Do not let credentials inherit into nested workflows or downstream templates.
• Run linting and validation in network and IAM zones separate from anything with release authority.
• Disable install lifecycle scripts, with the page's example setting:

ignore-scripts=true

• Generate SBOMs (CycloneDX or SPDX) as a build step. Sign each as an attestation tied to the artifact digest, and require SLSA Level 2 or higher provenance.

Scanning gates placement Secrets at commit or PR, SAST at PR, SCA at build against lockfiles (Google OSV is named), image scanning at registry push, DAST in staging, and IaC/CSPM before apply.

Deployment Admission control should reject unsigned containers, unneeded root, and images from untrusted public registries. Use read-only root filesystems and just-in-time admin access.

Endpoint Feed EDR compliance signals into UEM so a non-compliant device loses SCM, pipeline and publish access. Restrict CLI process exclusions to isolated developer environments. Run development in containers or VMs from hardened golden images. Keep mounts of sensitive host paths out of workspace containers.

Caveats

• Company Managed User accounts may be blocked from contributing to external open-source repositories. The page recommends standard accounts with MFA-enforced SSO for teams that publish or collaborate publicly.
• The seven-day cooldown rests on community detection removing malicious packages shortly after publication. The page gives no data on how quickly that happens.
• Several items are qualified with "wherever possible", including proxying all packages and sandboxing developers.
• Product references lean toward Google Cloud (Artifact Registry, Model Armor, OSV). The controls themselves are not tied to it.