The Emerging Pattern: Build Pipelines as Attack Surface

A critical vulnerability discovered in Google’s Gemini CLI has exposed a troubling blind spot in enterprise security: the assumption that build environments are inherently protected. The flaw allows remote code execution within CI/CD pipelines—the automated systems that developers rely on daily to validate, test, and deploy code.

While Google has already patched the vulnerability, the incident arrives alongside a coordinated campaign targeting SAP npm packages, where attackers embedded malicious preinstall scripts to harvest developer and CI/CD credentials. These aren’t isolated incidents—they represent a coordinated shift in attacker strategy toward compromising the infrastructure that builds software itself.

Why This Matters: The Trust Boundary Problem

CI/CD environments occupy a unique position in the software development lifecycle. They operate with elevated privileges—often holding cloud credentials, deployment keys, and access to production systems—yet they’re frequently treated as “internal” and therefore assumed to be safe.

That assumption is now broken.

When an attacker gains remote code execution in a CI/CD environment, they don’t just compromise a single application. They can:

  • Steal credentials at scale (as the SAP npm campaign demonstrated)
  • Inject backdoors into production artifacts before deployment
  • Lateral move across an organisation’s infrastructure
  • Remain hidden by blending malicious code with legitimate build outputs

The SAP npm incident is particularly instructive. Attackers didn’t target the developers directly—they poisoned a trusted dependency, trusting that the CI/CD pipeline would execute it with minimal scrutiny. And it worked.

Practical Defense Layers

Google and security researchers are recommending a three-part approach:

  1. Input Validation: Treat all external inputs to CI/CD pipelines—including pull request descriptions, commit messages, and dependencies—as untrusted. Sanitise and validate rigorously.

  2. Least Privilege Execution: Run CI/CD jobs with minimal necessary permissions. If a pipeline step only needs read access to a repository, it shouldn’t have deployment credentials.

  3. Environment Isolation: Segment build environments from production infrastructure. Use ephemeral containers, rotate credentials frequently, and monitor for anomalous activity.

The Compound Risk: Chaining Vulnerabilities

What makes this landscape particularly dangerous is emerging evidence that threat actors are linking multiple vulnerabilities into chains. The Gemini CLI flaw combined with dependency poisoning and prompt injection (as seen in the CVE-2025-53773 incident with GitHub Copilot) creates an attack narrative:

  1. Compromise a dependency
  2. Inject malicious prompts into code review systems
  3. Exploit CI/CD tools to execute the payload
  4. Exfiltrate credentials for persistence

Each step looks relatively benign in isolation. Together, they’re devastating.

What’s Still Unclear

  • How many organisations were affected by the Gemini CLI vulnerability before patching?
  • Are there similar vulnerabilities in other AI-assisted development tools?
  • How can developers distinguish between legitimate and malicious preinstall scripts in npm packages without deep inspection?
  • What’s the actual scope of the SAP campaign—was it only npm packages?

Next Steps for Teams

If you’re operating CI/CD pipelines:

  • Audit which tools have access to your build environment
  • Review recent deployments for unexpected changes
  • Implement code signing and attestation for all artifacts
  • Rotate all CI/CD credentials immediately
  • Enable detailed logging and monitoring of pipeline execution

The supply chain is no longer a theoretical risk—it’s an active battleground. Your build environment is part of your security perimeter now.

Source: Multiple Security Researchers