Securing Cloud Build Pipelines: A Deep Dive into Supply Chain Risks in GCP Cloud Build and GitHub Actions

Modern build pipelines are fast, flexible and a prime target for attackers. CI/CD tools like GCP Cloud Build and GitHub Actions now sit at the centre of cloud software delivery. If compromised, they offer a direct path to production.

This deep dive explores the most common risks in cloud-native build pipelines, real-world attack scenarios, and specific steps to harden your pipeline.

Why Build Pipelines Are High-Value Targets

• High privilege: Pipelines often have broad access to repositories, secrets, and deployment environments.
• Implied trust: Output artefacts are typically deployed automatically or reused downstream.
• High complexity: Many pipelines include third-party actions, external dependencies, and dynamic steps.

Attackers don’t need root access to your infrastructure. A single misconfigured pipeline can be enough.

Common Vulnerabilities in GCP Cloud Build and GitHub Actions

1. Untrusted Code in Build Steps

• Use of arbitrary scripts from public actions or images
• Lack of pinning to specific versions or commit SHAs

Risk: Attackers compromise a popular GitHub Action or public image and inject malicious code directly into your builds.

2. Secrets Leakage

• Hardcoded secrets in source or workflow configuration
• Overexposed service accounts in Cloud Build
• Inadequate secret scoping in GitHub Actions

Risk: Secrets may be printed in logs, accessed by untrusted steps, or reused in unsafe contexts.

3. Artefact Integrity Gaps

• No signature verification of base images or dependencies
• Lack of provenance or attestation tracking for outputs
• Artefacts written directly to public buckets or registries

Risk: Attackers replace trusted artefacts with backdoored versions or poison downstream builds.

4. Overprivileged Runners and Service Accounts

• GitHub runners or Cloud Build service accounts with excessive IAM permissions
• Access to modify infrastructure, deploy to production, or interact with unrelated projects

Risk: A compromised job can allow an attacker to pivot across environments.

Real Attack Path: Compromised GitHub Action + Secrets Reuse

1. A developer adds a GitHub Action that fetches a dependency.
2. The Action maintainer (or an attacker) updates it to include malicious code.
3. The workflow does not pin the Action to a commit or SHA.
4. It runs in a job with access to secrets.GCP_SERVICE_KEY.
5. The malicious Action exfiltrates the secret to an attacker-controlled domain.
6. The attacker uses the service key to access storage buckets or deploy infrastructure.

This is a real-world, repeatable exploit path and it doesn’t require breaking into your cloud account.

How to Harden Cloud Build and GitHub Actions Pipelines

1. Pin Dependencies and Actions

• Always pin GitHub Actions using SHA, not mutable version tags
• Use image digests when referencing containers in Cloud Build
• Avoid using latest or unpinned tags

‍2. Scope Secrets Tightly

• Prefer short-lived credentials (e.g. Workload Identity Federation in GCP)
• Limit GitHub secrets to only the jobs that need them
• Avoid injecting secrets into the environment unnecessarily

3. Implement Artefact Signing and Verification

• Use GCP’s provenance metadata
• Sign artefacts with cosign
• Enforce signature verification before deployment

4. Restrict Permissions for Runners and Service Accounts

• Apply least privilege to Cloud Build roles (e.g. cloudbuild.serviceAgent)
• Create per-project GitHub runners with scoped Personal Access Tokens (PATs)
• Block outbound network access unless explicitly needed

5. Monitor and Audit Build Steps

• Enable Cloud Audit Logs for Cloud Build jobs
• Review GitHub Action logs for unexpected outbound connections
• Alert on use of unverified or unpinned third-party Actions

Secure-by-Design Build Pipeline Checklist

Conclusion

Cloud-native build pipelines are no longer a developer convenience, they’re part of your production attack surface. If you don’t control them, someone else might.

By using least privilege, pinning every dependency, scoping secrets tightly, and verifying outputs, you can close off the most common and dangerous attack paths.

CI/CD isn’t just a delivery mechanism. It’s a security control. Secure it like one.

‍