The most dangerous code in a modern software project may not look like code at all. It may be a few lines of YAML in .github/workflows, wired to run tests, publish packages, sign releases, touch cloud accounts, and trust whatever came in from a pull request.
That is the uncomfortable lesson in SecurityWeek’s June 24 report on a new class of exploitable CI/CD workflow flaws. Security firm Novee says it scanned roughly 30,000 high impact repositories, flagged 654 in one pass, and confirmed more than 300 fully exploitable chains that could lead to attacker controlled code execution, credential theft, or outright supply chain compromise.
This goes far beyond one maintainer forgetting to escape a string. Novee says it found confirmed issues involving Microsoft, Google, Apache, Cloudflare, and the Python Software Foundation. The industry has spent years treating build automation like plumbing, then acting surprised when attackers realize the plumbing has the keys.
Workflow code is privileged code
CI/CD workflows are often discussed as boring project glue. That framing is wrong. The NSA and CISA define CI/CD pipelines as part of the software supply chain, alongside source control, build systems, infrastructure templates, and package dependencies. Their guidance warns that pipeline compromise can modify source code, dependencies, build configuration, and deployment artifacts.
That is exactly why workflow bugs matter. SecurityWeek summarizes Novee’s finding this way: workflows with fewer privileges can be triggered by untrusted pull requests or comments, then pass data into more powerful workflows that authenticate to cloud providers with maintainer permissions. In plain English, an outsider gets a project to run a seemingly harmless automation step, then that step hands attacker controlled data to the part of the pipeline allowed to publish software or touch secrets.
GitHub’s own documentation tells maintainers to treat fields such as pull request titles, issue bodies, branch names, and other github context values as untrusted input. The docs even warn that a branch name can become a shell injection payload if a workflow drops it into a command without care. That should be enough to end the fantasy that workflow files are just configuration.
If a file can run shell commands, approve pull requests, publish packages, sign releases, or authenticate to AWS and GCP, it is privileged code. That means real review, clear ownership, and threat modeling. Instead, too much of the industry still treats it like a dusty drawer where automation snippets go to die.
The examples are not obscure
Novee’s report is vendor research, so it should not be swallowed whole without context. But the examples are concrete enough to take seriously.
According to Novee’s report, Microsoft Azure Sentinel had a workflow path where a pull request comment could run attacker code in CI and steal a GitHub App key that did not expire, with the behavior confirmed by MSRC. Novee says Google’s official AI Agent Development Kit samples had a path where one pull request could gain authenticated control over an associated Google Cloud project with roles/owner. Apache Doris had two independent attack paths requiring no click from a maintainer, including one involving pull request comments and hardcoded CI credentials. Cloudflare’s Workers SDK could execute arbitrary commands from a crafted branch name. Python’s Black formatter could expose an automation token able to post, approve, and manipulate pull requests as the project bot.
Those are not hobby projects maintained by one exhausted person after work. They are attached to some of the most capable engineering organizations on earth. If their workflow code can get this messy, the rest of the industry should be sweating.
The downstream stakes are just as ugly. Novee says these patterns could enable malicious publishing to npm, PyPI, crates.io, Docker/GHCR, and Helm, along with forged CI checks, stolen cloud credentials, compromised self hosted runners, and bot impersonation. That is the software supply chain in miniature: a little automation mistake in one repository can become someone else’s poisoned dependency.
We have seen versions of this before. Codecov disclosed in 2021 that an attacker modified its Bash Uploader, affecting users of the Bash Uploader, GitHub Action, CircleCI Orb, and Bitrise Step. GitHub’s advisory for the compromised tj-actions/changed-files action says the incident affected more than 23,000 repositories and exposed CI/CD secrets in logs. Red Hat’s writeup on the xz incident shows how a trusted open source release path can hide a backdoor in plain sight until somebody notices the wrong thing.
The common failure is blunt: trusted automation became the attack surface.
AI is scaling creation faster than verification
The AI angle here is easy to overstate and just as easy to dismiss. AI did not invent bad CI/CD. People have been copying and pasting dangerous workflow snippets for years. Open pull requests are part of how open source works.
The problem is speed. Novee says agentic coding is helping reproduce insecure CI/CD patterns across repositories, and its own research used AI agents to narrow and validate findings across a large scan. That cuts both ways. AI can absolutely help defenders find chains humans miss. It can also generate workflow YAML that looks plausible, passes review because nobody wants to stare at build config, and quietly crosses a trust boundary it does not understand.
GitHub, OpenSSF, and the NSA/CISA guidance already point to real mitigations. GitHub recommends pinning actions to full length commit SHAs, using CODEOWNERS for workflow changes, restricting token permissions, and avoiding long lived secrets. GitHub’s OpenID Connect docs explain how workflows can request short lived cloud credentials instead of storing static keys. OpenSSF’s guidance names the attack surfaces directly, including untrusted code in privileged workflows, code injection, malicious releases, tag renaming attacks, and unsafe caches.
The advice exists. The hard part is forcing the industry to treat it as routine engineering instead of optional homework.
Security advice that depends on every maintainer reading every best practice page, interpreting it correctly, applying it perfectly, and then keeping it correct while AI agents churn out more configuration is wishful thinking with a README.
The bill belongs to the companies that benefit
There is a predictable response to this kind of story: maintainers should be more careful. Sure. They should. So should everyone who writes code that touches production.
But that answer lets the powerful off the hook. Big companies get enormous value from open source, from GitHub Actions, from package registries, from volunteer maintainers, and from the invisible build machinery that makes modern software feel effortless. They also have the security teams, budgets, and platform control to make the defaults safer.
That means funding security review for workflow code. It means treating .github/workflows changes as high risk changes by default. It means better scanners that can reason across workflows instead of matching patterns in one YAML file at a time. An academic survey of GitHub Actions scanners found only nine maintained open source scanners after curating 30 candidates, which says a lot about how underbuilt this area still is.
It also means no more pretending that agent generated automation is harmless because it came wrapped in productivity language. If AI helps create the pipeline, AI also needs to help verify it. If a company wants to brag about developers shipping faster, it can pay for the guardrails that keep fast from becoming reckless.
Open source is one of the best things the tech industry ever built. Protecting it means funding the security work instead of scolding maintainers after every incident. It means ending the habit of dumping critical infrastructure risk onto people who never agreed to be the unpaid security department for the entire internet.
YAML can publish software, steal secrets, and move code into production. The industry should start acting like it.