Hardening CI/CD Against Modern Supply-Chain Attacks

Software supply-chain security is no longer limited to checking source code for known vulnerabilities. According to Google Threat Intelligence and Mandiant, modern attacks increasingly focus on the trusted tools and identities that connect developer workstations to repositories, build systems, cloud platforms, and production releases.

The central risk is systemic trust. A developer workstation may hold repository credentials and cloud session material. A CI/CD runner may be authorized to retrieve private dependencies, publish artifacts, or deploy infrastructure. A package registry, IDE extension, marketplace action, or shared build cache may be trusted by automated workflows. Compromise at any one of these points can provide a path into later stages of the software development lifecycle.

Mandiant’s guidance describes a defense-in-depth model spanning endpoints, code repositories, dependencies and artifacts, CI/CD infrastructure, and deployment environments. The recommendations are not based on a single malware family or named threat actor. Rather, they address attack methods that the organization says have appeared in recent software supply-chain campaigns, including developer-targeted credential theft, malicious extensions, dependency poisoning, cache manipulation, OIDC token abuse, and mutable reference substitution.

Why the developer environment is part of the production attack surface

Developer machines are attractive because they often combine access to proprietary code, source-control systems, cloud consoles, package registries, and deployment workflows. Google Threat Intelligence and Mandiant identify personal access tokens, SSH keys, API tokens, and active session credentials as high-value material that may be exposed from local engineering environments.

The research describes several routes into this layer. These include tailored social engineering, malicious IDE or browser extensions, and typosquatted local dependencies. Third-party programming tools and AI development tools are also treated as supply-chain concerns because they may receive broad access to source trees, local files, or build-related data.

The confirmed defensive implication is that endpoint security controls cannot stop at traditional office applications. Mandiant recommends monitoring trusted IDE process trees for unexpected file access, unusual child-process creation, and unauthorized outbound connections. Endpoint detection and response signals should also feed unified endpoint management so that a device falling out of compliance can lose access to source-control systems, pipeline execution, or code publication.

Organizations should standardize approved IDE versions, browser integrations, and extensions. Marketplace access should be restricted to vetted software, with a maintained inventory and the ability to block a newly identified extension quickly. Containerized development environments or dedicated virtual machines can further limit the ability of a poisoned dependency or post-install script to reach sensitive host files. The research recommends hardened images, network isolation from production, and centralized logging for sandbox activity.

Credentials are a bridge between pipeline stages

A stolen credential can turn a local compromise into a repository or cloud compromise. The report therefore emphasizes reducing both credential lifetime and permission scope.

For source-control access, Mandiant recommends moving away from broad, long-lived classic personal access tokens toward fine-grained tokens with minimal permissions and short time-to-live values. It also recommends cryptographically verified SSH authentication backed by hardware security keys where appropriate. For automated integrations, GitHub Apps are preferred over service-account personal access tokens because their access tokens are short-lived and narrowly scoped.

Secrets should not be placed in environment variables or committed to repositories. Local .env files should be excluded from source trees and, where AI tools are used, from the model’s working context whenever possible. Runtime secret-management features should provide credentials only when a workload needs them.

For cloud-connected workflows, the report recommends federated, ephemeral identities using OpenID Connect rather than persistent automation secrets. OIDC does not eliminate risk: an attacker who can extract or misuse a token during a workflow may still obtain access within the token’s permitted scope. That makes trust conditions important. Teams should restrict which repositories, branches, workflows, and environments can request federated credentials, and should review cloud audit logs for unexpected use of short-lived identities.

Repositories and dependencies need stronger integrity controls

Source repositories should be treated as authoritative records, not merely collaboration tools. Mandiant recommends a zero-direct-to-main model in which changes arrive through isolated branches, peer review, and successful automated checks. Administrative bypasses and force-pushes on canonical branches should be disabled or tightly controlled. Audit histories should be reviewed for unexpected chronology, unauthorized changes, and repositories that may be used as code-exfiltration locations.

Dependency resolution is another important trust boundary. Dynamic version ranges, including caret, tilde, and wildcard specifications, can cause builds to receive a different package than the one previously reviewed. The research recommends exact version pinning backed by cryptographically verified lockfiles. Blind remote execution patterns should be blocked in favor of explicitly identified vendor containers referenced by immutable SHA-256 digests.

Mandiant also recommends a release-age cooldown for newly published public packages, with seven days given as an example of a minimum buffer. The purpose is to give the community time to identify and remove poisoned releases before they enter internal builds. External packages and container images should pass through centralized proxies or registries where they can be cached, inspected, quarantined, and approved. Internal and public repositories should remain distinct to reduce dependency-confusion risk.

Scanning remains useful, but point-in-time scanning is not enough. Stored artifacts should be reevaluated as new vulnerability information becomes available. Software Composition Analysis can be combined with reachability analysis so teams prioritize components that are actually used. Vulnerability Exploitability eXchange statements can help document findings that do not apply to a particular build.

CI/CD runners are privileged execution environments

Build runners often have access to source code, package registries, cloud APIs, and publishing credentials. The research identifies shared build caches as one pipeline manipulation risk. A malicious pull request may write corrupted content into a cache that a later trusted build retrieves. Mandiant recommends separating cache access by branch privilege and rejecting cache writes from unauthenticated forks.

Runner persistence is another concern. Single-use, ephemeral runners provide a clean environment for each job and are automatically destroyed afterward. Self-hosted runners should have restricted outbound connectivity, limited to approved repository APIs and registries where feasible. Early validation tasks should be separated from runners that can deploy to production.

Pull requests from untrusted sources should not receive secrets or deployment-grade runner access without explicit administrative approval. Workflows should begin with read-only or no permissions and request only the access needed for a particular job. Nested workflows and downstream templates should not automatically inherit credentials. Third-party actions and marketplace plugins should be governed through an approval process.

Action and image references require particular care. A mutable tag can be moved to different content without changing the name used by a workflow. The report recommends pinning third-party actions to full commit hashes and container images to immutable digests. This control should cover base images, sidecars, and initialization containers, not only the primary application image.

Provenance must be verified, not merely recorded

Cryptographic signing and provenance can help establish where an artifact came from and which workflow and source commit produced it. However, a signature is meaningful only when deployment systems verify it against the expected build identity and immutable artifact digest.

Mandiant recommends replacing long-lived registry publishing credentials with short-lived, identity-bound tokens issued to the relevant build workflow. Builds should also generate a software bill of materials in a recognized format such as CycloneDX or SPDX, then sign the SBOM as an attestation tied to the artifact digest. This creates a tamper-evident inventory that can be mapped to affected releases when new vulnerabilities emerge.

Detection and threat-hunting priorities

The source guidance does not provide a specific detection-rule package or list of indicators of compromise. Organizations will therefore need to translate the architectural recommendations into local telemetry and alert logic.

• Review IDE and browser-extension inventories for unapproved additions, unexpected version changes, and newly granted access.
• Monitor IDE process trees for unusual child processes, sensitive-file access, and outbound connections that do not match normal development workflows.
• Alert on personal access token creation, permission expansion, unusual API activity, unexpected SSH-key use, and access from devices that fail posture checks.
• Audit workflow changes, action-reference changes, cache writes, fork-triggered jobs, and attempts to access secrets from untrusted pull requests.
• Correlate OIDC token issuance with repository, branch, workflow, environment, and cloud-resource activity. Investigate use outside the expected build identity or deployment path.
• Compare resolved dependency versions, container digests, action commit hashes, SBOMs, and provenance attestations against approved records.
• Look for force-pushes, branch-protection bypasses, unexplained changes in commit chronology, and artifacts published by unexpected identities.

What organizations should do now

1. Inventory trust relationships. Document which developers, actions, runners, registries, cloud identities, and deployment systems can read, modify, publish, or deploy.
2. Reduce credential exposure. Replace broad and persistent tokens with short-lived, fine-grained credentials, hardware-backed authentication, and federated workload identities.
3. Make builds reproducible and immutable. Pin dependencies, actions, and images; use verified lockfiles; and block mutable references in production workflows.
4. Isolate execution. Use ephemeral runners, separate untrusted validation from release workflows, restrict runner egress, and isolate developer sandboxes from production.
5. Control external software. Route packages and images through internal proxies, quarantine new components, enforce a release-age policy, and prevent dependency confusion.
6. Enforce repository governance. Require review and CI checks before merging, protect canonical branches, and preserve an append-only audit trail.
7. Verify release integrity. Sign artifacts and SBOMs, validate provenance at admission, and permit deployment only from approved build identities and immutable digests.
8. Connect prevention to response. Feed endpoint, repository, workflow, cloud, registry, and deployment logs into centralized monitoring so a compromised identity or workstation can be isolated quickly.

Conclusion

Google Threat Intelligence and Mandiant’s analysis shows why CI/CD security must be designed as a connected system. Developer endpoints, source repositories, dependencies, runners, cloud identities, artifacts, and production workloads form a continuous chain of trust. Breaking that chain requires more than vulnerability scanning: it requires short-lived access, immutable references, isolated execution, verified provenance, controlled dependencies, and continuous monitoring.

The source does not identify a single malware family, threat actor, victim set, CVE, or IOC in this guidance. Its broader assessment is that organizations should assume trusted development components may become attack paths and build controls that limit the blast radius of any individual compromise.

Sources

Google Threat Intelligence / Mandiant: Proactive Defense: Hardening Code Pipelines and CI/CD Infrastructure