Your CI pipeline is an attack surface now

Why CI is the target

Three structural facts make the pipeline attractive, and they are true of almost every team.

CI runs with real credentials

The whole job of a deploy workflow is to authenticate to your cloud, push to your buckets, invalidate your CDN, write to your database. To do that, it holds powerful secrets. Whatever the runner can read, a malicious step in that runner can read too.

CI runs untrusted-ish code constantly

Every third-party action you reference, every dependency you install, every fork's pull request runs code inside your pipeline. The trust boundary is enormous and mostly invisible.

A stolen CI secret often keeps working

This is the quiet killer. If your workflow authenticates with a long-lived access key, an attacker who exfiltrates it has a credential that works until a human notices and rotates it, which is frequently never. The breach outlives the build. Megalodon did not need to be sophisticated, because most pipelines are soft in exactly these three places.

How we think about hardening a pipeline

There is no product to buy here. There are a handful of cheap, boring practices that, taken together, defang the whole category. This is the posture we hold our own work to and the first thing we look at in a client's pipeline.

Short-lived credentials, never long-lived keys

Move CI authentication to OIDC. Instead of storing a static cloud access key, the workflow requests a short-lived token at run time, scoped to that repository and job, that expires when the job ends. The difference under attack is total: a stolen static key works until someone rotates it; a stolen OIDC token is dead weight the moment the job finishes. This turns "attacker now has our cloud" into "attacker has a token that already expired." It is the single most important change on this list.

Pin third-party actions to commit hashes

When you write uses: some/action@v3, you are trusting whoever controls that tag to never repoint it at malicious code, forever. Tags are mutable; a hijacked account can repoint v3 at a payload that flows straight into your pipeline. Pinning to a full commit hash freezes exactly the code you reviewed. Pair it with automated updates so security patches still reach you on your terms.

Least privilege on the build token

A workflow with no explicit permissions block inherits the repository default, which is often read and write across the board. Set the default to read-only and grant write only to the job that genuinely needs it. If a step is ever compromised, this is the difference between "it could read the repo" and "it could rewrite your releases."

Protect the branch so injected commits cannot just land

Megalodon's whole technique was pushing commits directly. Requiring a pull request and a review before anything merges to your deploy branch means a malicious commit has to get past a human, not just past an automated push. Combine it with secret scanning and push protection so a leaked credential is caught at the door.

What we are not claiming

• Not that the technique is novel. CI/CD supply-chain attacks are a known and growing class; Megalodon's contribution was scale and automation, not invention. Treat anyone selling this as a brand-new threat with suspicion.
• Not that a tool fixes it. There are useful scanners and policy engines, and we use some, but the core of this is configuration and discipline, not a product you install. If a vendor says their box makes supply-chain risk go away, that is the tell.
• Not that every organization needs the same depth. A solo project and a regulated fintech have different risk and different budgets. The practices above are a floor worth reaching; how far past it you go is a real decision, not a checklist.
• Not that we are finished. Holding this posture is ongoing work. We run our own fleet on these practices and audit our own pipelines the way we audit a client's, and where we find a gap (including pipelines still on the old long-lived-key pattern) we are migrating them. We would rather say that than pretend the work is ever fully done.

One-sentence takeaway

Your CI pipeline holds the keys to your infrastructure, an automated campaign just proved how cheaply those keys get stolen at scale, and the fix is not a product but four boring practices: short-lived OIDC credentials, hash-pinned actions, least-privilege build tokens, and a protected branch.