Hardening CI/CD Pipelines: Google's Software Supply Chain Guide

Executive Summary

Sophisticated cyber threat actors are systematically shifting their operational focus toward software engineering lifecycles, targeting developer environments, continuous integration/continuous delivery (CI/CD) pipelines, and software repositories. In response, Google Cloud Threat Intelligence, Mandiant Services, and the Google Threat Analysis Group (TAG) have published a comprehensive architectural blueprint detailing defense-in-depth controls across the modern Software Development Lifecycle (SDLC).

Adversaries have evolved beyond simple credential theft to execute multi-stage supply chain attacks. These campaigns weaponize developer IDE extensions, poison shared GitHub Actions build caches, abuse OpenID Connect (OIDC) tokens, and subvert mutable action tags to publish compromised software packages that still carry legitimate cryptographic provenance. Securing this surface requires platform architects and security teams to treat every stage of the pipeline as an interdependent security domain.

Technical Vulnerability Analysis & Attack Chain

Modern CI/CD attack campaigns converge across three primary threat primitives: endpoint compromise, pipeline poisoning, and artifact subversion. Adversaries routinely target developer workstations to extract personal access tokens (PATs), SSH private keys, and uncommitted .env configuration files. With developer credentials secured, attackers target GitHub Actions, GitLab CI, and Jenkins environments via Poisoned Pipeline Execution (PPE).

In typical PPE scenarios, attackers submit crafted pull requests that trigger automated build workflows. If the execution environment relies on persistent, self-hosted runners or shared cross-branch caches, the untrusted pull request can write malicious binaries directly into the shared cache. When a subsequent production release build runs, it retrieves the poisoned cache and packages malicious code into downstream release artifacts.

Furthermore, adversaries exploit mutable version tags (e.g. actions/checkout@v4). Because tags can be silently updated to point to malicious commit hashes, attackers compromise upstream action maintainers or dependencies to execute code within runner contexts. Once inside the runner, intruders harvest federated OIDC tokens to pivot into enterprise cloud accounts (AWS, GCP, Azure) without triggering traditional static credential alerts.

MITRE ATT&CK Tactics, Techniques & Procedures (TTPs)

Threat Actor Profile & Campaign Attribution

State-sponsored espionage clusters (including Russian SVR / APT29, Chinese cyber operations, and North Korean Lazarus affiliates) and financially motivated access brokers increasingly prioritize CI/CD targets. State actors leverage compromised developer accounts to insert subtle backdoors into commercial software products, targeting downstream government and defense clients.

Simultaneously, opportunistic actors deploy automated scanners searching for exposed Jenkins instances, GitLab API tokens, and public GitHub repository secrets. Stolen credentials are used to hijack build capacity for cryptocurrency mining or to stage payment skimmers in ecommerce web applications.

Detection & SOC Mitigation Playbook

1. Patch & Workaround Guidance

• Mandate Ephemeral Single-Use Runners: Ensure all build runners are spun up dynamically inside isolated containers or microVMs and destroyed immediately upon job completion to deny attackers persistence.
• Migrate to OIDC Federated Identities: Remove all static cloud access keys (e.g., AWS_ACCESS_KEY_ID, service account JSON keys) from repository secrets. Use short-lived OIDC tokens scoped strictly to specific workflows and branches.
• Implement 7-Day Package Release Cooldown: Enforce a minimum 7-day release-age buffer (e.g., using npm minimumReleaseAge or private virtual registries) before public package versions become installable internally, allowing community threat intelligence to detect malicious packages first.
• Pin Immutable SHA-256 Digests: Prohibit the use of mutable tags (e.g. @v1, :latest). Pin all third-party actions and container base images to immutable SHA-256 digests (@sha256:...).

2. Network & Perimeter Defenses

• Runner Network Egress Filtering: Restrict outbound network access from build runners using perimeter firewalls or network policies. Allow outbound traffic only to authorized package registries and SCM endpoints.
• Disable Lifecycle Scripts: Standardize package manager configurations to disable execution of post-install scripts during automated builds (npm config set ignore-scripts true).
• Cache Isolation: Configure CI/CD cache storage to enforce branch-level boundary isolation, preventing untrusted pull requests from writing to production caches.

3. Endpoint Detection & Hunting Query

Security teams should monitor CI/CD runner environments for unauthorized network connections and anomalous process execution spawning from build runners.

title: Suspicious Process Spawning from CI/CD Build Runner
id: b8394c22-7711-4f91-8841-cicd048
status: experimental
description: Detects suspicious interactive shells, network utilities, or credential access commands spawning from CI/CD runner agent processes
author: CyberNewsAI Threat Intelligence
references:
  - https://cloud.google.com/blog/topics/threat-intelligence/hardening-code-pipelines-and-ci-cd-infrastructure/
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/Runner.Listener'
      - '/gitlab-runner'
      - '/jenkins'
      - '/actions-runner'
  selection_child:
    Image|endswith:
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/bash'
      - '/sh'
      - '/python'
      - '/python3'
    CommandLine|contains:
      - 'http://'
      - 'https://'
      - 'id_rsa'
      - '.env'
      - 'OIDC'
      - 'ACTIONS_ID_TOKEN_REQUEST_TOKEN'
  condition: selection_parent and selection_child
fields:
  - ComputerName
  - User
  - ParentImage
  - Image
  - CommandLine
falsepositives:
  - Legitimate build scripts downloading explicit dependencies from approved domains
level: high
tags:
  - attack.execution
  - attack.t1059.004
  - attack.credential_access

Hunting query for Microsoft Sentinel / Azure Log Analytics (KQL):

// Hunt for CI/CD runners initiating outbound network connections to non-allowlisted IP addresses
DeviceNetworkEvents
| where InitiatingProcessFileName in~ ("Runner.Worker", "gitlab-runner", "jenkins-agent", "actions-runner")
| where RemotePort in (80, 443, 8080, 22)
| where not(RemoteUrl has_any (".github.com", ".gitlab.com", ".npmjs.org", ".pypi.org", ".pkg.dev", ".docker.io"))
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemoteUrl, RemotePort
| summarize ConnectionCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by DeviceName, InitiatingProcessFileName, RemoteIP, RemoteUrl
| sort by ConnectionCount desc

CI/CD Exploitation Indicators & Artifact Patterns