Pipelines on Fire: Why Your CI/CD Tools Are the New Cyber Battlefield

Fifteen years in, and the conversation I have most often with security leads still starts the same way: how's your perimeter, how's your endpoint coverage, how's your SOC staffed? Almost nobody opens with "how's your pipeline." That's the gap I want to talk about, because 2025 was the year the gap turned into a crater.

Here's the number that should reorder every security roadmap for 2026: major DevOps platforms — GitHub, GitLab, Azure DevOps, and Atlassian's Jira and Bitbucket — patched 236 vulnerabilities in 2025, according to GitProtect's DevOps Threats Unwrapped report. Of those, 59% were rated high or critical: 14 critical, 126 high, 75 medium, 21 low. The trend line is worse than the total. Critical flaws jumped from 4 in the first half of the year to 10 in the second. High-severity findings climbed 55%, from 39 to 87 over the same stretch. November 2025 alone produced 36 patched vulnerabilities — 15% of the entire year's total in one month. These aren't obscure internal tools. GitHub alone hosts more than 180 million developers across 630 million repositories. When the platforms holding that much code accelerate their vulnerability disclosures quarter over quarter, that's not noise. That's a trend with a direction (DevOps.com, SecurityBrief).

"You Hack the Runner, and You're in the Whole Building With a Master Key"

I want to be careful here and use a real source, because this argument gets thrown around a lot without anyone actually backing it up. Paweł Budzan, a technology consultant and AI and cybersecurity architect at Xopero, put the stakes in terms I haven't heard bettered: a compromised CI/CD pipeline hands an attacker the repo, the cloud, the production secrets, and the deployment path all at once. Hack the runner, he said, and you're not in one room — you're in the whole building with a master key to every door. His point about "shift-left" culture stung a little because I've made the same mistake myself: plenty of teams scan the code, call it a day, and never apply the same scrutiny to the infrastructure that actually moves that code into production (GitProtect/Xopero). 

Budzan's list of the ten most commonly overlooked CI/CD vulnerabilities reads like a checklist written by someone who's cleaned up after every one of them: secrets echoed into build logs and never scrubbed; runners granted full cluster-admin rights because restricting them "might break the build"; a single shared runner handling both untrusted external pull requests and production deployments; blind trust in third-party GitHub Actions with a few stars and no real vetting; long-lived service tokens nobody rotates because rotation is scary; unprotected workflow YAML files that get far less code-review scrutiny than application logic. None of these are exotic. That's exactly the problem.

When AI Turns a Script Kiddie Into a Supply-Chain Threat

The part of Budzan's analysis that actually changed how I think about this: the barrier to entry for a serious pipeline attack has, in his words, dropped to the level of writing prompts in English. Malicious large language models — he named WormGPT and FraudGPT specifically, tools sold on dark-web forums and Telegram channels for a monthly fee — are trained specifically for offensive use, with none of the guardrails a mainstream model would apply. An attacker doesn't need deep AWS or Git expertise anymore. They can feed a workflow YAML file into one of these tools and ask it to locate secrets or draft a plausible-looking pull request. What comes back is a clean, credible "fix" that sails through code review, and when the pipeline runs, the token leaks straight out. Budzan's own estimate of the human-versus-sophistication split surprised me: from his practice, it's roughly 80% human error and 20% advanced attack — a developer under sprint pressure who leaves a token in a config file, tells themselves they'll fix it after the weekend, and never does (GitProtect/Xopero).

The real-world version of that pattern already happened. In March 2025, attackers compromised the popular tj-actions/changed-files GitHub Action — retroactively rewriting version tags to point at a malicious commit — and the poisoned action ended up exposed in more than 23,000 repositories before it was caught and patched. It didn't require breaking any cryptography. It required trust in a dependency nobody was individually vetting (GitHub Advisory Database). 

The CI/CD Tools Themselves Are Now the Target, Not Just the Delivery Mechanism

Then there's the newer wrinkle: the AI tooling that's increasingly wired directly into these pipelines is itself shipping critical flaws. In April 2026, researchers at Novee Security disclosed a maximum-severity, CVSS 10.0 remote code execution vulnerability in Google's Gemini CLI and its companion run-gemini-cli GitHub Action — a flaw that let an unprivileged external attacker force their own malicious content to load as the tool's configuration, effectively turning an AI coding assistant embedded in a CI/CD workflow into a remote-execution foothold. Google assigned it the highest score the scale allows. This is the pattern Budzan's framework predicts almost exactly: the pipeline as master key, an AI tool as the unguarded runner, and a single crafted input as the way in (Novee Security). 

The Uncomfortable Final Word: No Defense Is 100%, So Plan For the Day It Fails

What I respect about Budzan's take is that he doesn't oversell prevention. Backup and disaster recovery, he argues, are the actual last line of defense — and anyone who claims a tool stops 100% of attacks is selling you something, full stop. His specific standard for what counts as a real backup is worth repeating exactly because it's so unglamorous: isolated, offline, in a separate cloud tenant and a separate account — not a separate folder in the same S3 bucket, and definitely not sitting in the same AWS account as production. If the same compromised credentials that let an attacker into your pipeline can also reach your backups, you don't have a backup. You have a second copy of the crime scene (GitProtect/Xopero).

Where This Leaves Security Leaders

Every thread here points the same direction: CI/CD pipelines have quietly become as valuable a target as production itself, and in most organizations they're guarded with a fraction of the rigor. The 236 patched vulnerabilities, the accelerating severity curve through the back half of 2025, the tj-actions compromise, the Gemini CLI RCE, and Budzan's own field experience all describe the same failure mode from different angles: trust extended to a pipeline, a runner, a third-party action, or an AI assistant, with nobody watching that trust closely enough.

I don't think the fix is more scanning tools bolted onto the same workflow. It's treating the pipeline itself — the runners, the tokens, the workflow files, the AI assistants wired into it — with the same access control, isolation, and adversarial testing you'd apply to a production database. And it's accepting, the way Budzan does, that prevention will eventually fail, so the backup sitting behind it needs to be somewhere the attacker who got in through the front door can't also reach. Most teams I talk to still don't have that. The threat landscape isn't going to wait for them to build it.

Sources are linked inline throughout. Reporting and analysis are current as of July 2026.