The vulnerability nobody wrote

Last week researchers at Novee Security published something worth your attention if your team ships software through GitHub. They named it Cordyceps.

They scanned around 30,000 high-impact repositories and found more than 300 fully exploitable, including ones at Microsoft, Google, Apache, Cloudflare and the Python Software Foundation. The entry requirement for an attacker was not a stolen credential, not an insider, not a clever phish. A free GitHub account was enough to forge approvals, push code, or steal CI secrets.

Read that again. Not a zero-day in a library. A configuration pattern in the pipeline that let an untrusted pull request run with privileges it should never have had. On Microsoft’s Azure Sentinel, a single comment on a pull request could run anonymous code and lift a non-expiring GitHub App key. On Google’s AI agent toolkit, a pull request could execute attacker code and take over a cloud repository.

Here is the part I want you to sit with, because it is the whole point of this issue. In the researchers’ own words, the flaw “hides from scanners because, technically, every individual piece is working as designed. The workflow does what it was told. The vulnerability exists only in the composition: untrusted data crossing a trust boundary that no one audited.”

That is not a CI/CD story. That is the story of modern software security.

Why the scanner stayed silent

We have spent a decade buying tools that look at pieces. A scanner reads a file and asks one question: is this line wrong? Cordyceps is invisible to that question, because no single line is wrong. The YAML is valid. The permissions are real. The workflow runs exactly as written. The risk lives in how the parts connect, in a boundary between “untrusted contributor” and “trusted automation” that worked as designed and was never reviewed as a whole.

You cannot scan your way to catching that. It takes someone who can read the composition and ask the awkward question: what happens if the person opening this pull request is hostile?

And now it ships at machine speed

The same researchers said the quiet part out loud: “the nature of agentic coding means these CI/CD vulnerabilities are reproduced persistently, at scale.” AI assistants and coding agents reproduce the same permissive patterns confidently and fast, in repo after repo. The misconfiguration that used to spread slowly by copy-paste now ships at machine speed.

This is the same gap I keep coming back to. AI writes the code. Few people review the risk. And the risk that matters most is rarely a single bad line. It is the composition: a permission too broad, a boundary nobody owns, an agent handed more trust than a fast junior should ever get.

What actually helps

Four things, none of them a new product to buy:

1. Treat every pull request from outside your trust boundary as untrusted input, the same way you treat a form field a stranger filled in.
2. Give pipeline jobs the least privilege they need, and assume any job that touches an untrusted pull request can be hijacked.
3. Review the composition, not just the diff. The dangerous question is how the parts connect, not whether each file looks clean on its own.
4. Decide on purpose what may be AI-generated with light review, and what needs human authorship and a senior sign-off before it ships.

None of that is exotic. It is judgement and ownership, wired into how you ship, instead of a control bolted on at the end. That is what building security in actually means.

Where this lands for your team

This is exactly what I train, live and hands-on, not on slides. In workshops we work on your own pipeline and repositories wherever that is practical and agreed. If the AI-and-pipeline side of this is on your mind, I put the engineering version of it on one page: cyberment.ee/ai-code-security.

Build it in. Don’t bolt it on.