Let’s play out a scenario.
Say ransomware hits one of your dev laptops today.
What could it touch? How far could it actually go?
Now most folks will say: “Well, we’ve got MFA on AWS, our IAM users are cleaned up, roles are in place…”
Cool. But that’s usually where the IAM story stops.
Meanwhile—your CI/CD pipeline is out here shipping code with long-lived AWS tokens.
Slack is kicking off Terraform runs.
And your secrets? Sometimes rotated, often shared, and usually… nobody’s really sure where they live.
This is where IAM blind spots show up.
And if you’re not paying attention, your CI/CD turns into your biggest attack surface.
CI/CD Is Infrastructure. Treat It That Way.
Think about it. Your pipeline does everything.
- Ships code to prod
- Spins up infra
- Rolls back bugs
- Handles secrets
- Pushes features at 2am
It’s basically your company’s central nervous system.
But somehow… it still gets treated like “just dev tooling.”
And that’s where things break. Because we’ve seen some wild stuff out there:
- GitHub Actions with full admin rights in AWS
- Shared CI runners all using the same root token
- No audit trails for deployments
- Dev secrets hardcoded in .env files
- Staging jobs using prod credentials “just for now”
It all works. Until it doesn’t.
One leaked token, one compromised dev machine—and boom, you’ve got a straight path to prod.
IAM Isn’t Just About Logins—It’s About Actions
When people think “IAM,” they usually think user logins and roles.
But that’s just the front door.
The real question is: who can act on your systems?
And most of your actions? They’re not human anymore. They’re automated.
CI/CD pipelines today can:
- Deploy infrastructure
- Change DNS records
- Write to S3
- Rotate secrets
- Push config to production
So your pipeline is basically an engineer with root access.
If it can act like a human—and more consistently than a human—then it needs to be treated like one. With the same guardrails.
How to Secure CI/CD (Without Slowing Everything Down)
Let’s be clear: nobody’s saying slow down. We’re saying build smarter.
Here’s how to lock things down without becoming the “Department of No”:
- ✅ Use short-lived credentials
Ditch long-lived access keys in pipelines. Switch to OIDC or time-limited IAM roles. - ✅ Split permissions
Don’t let staging jobs write to production. Create separate roles and secrets for each environment. - ✅ Audit pipelines like users
Ask: who can deploy? Where? When? And how? - ✅ Rotate secrets automatically
This should be table stakes. CI/CD secrets go stale fast—don’t wait for a breach. - ✅ Log everything
Especially deploys outside work hours, weird IPs, or new runners. Know what normal looks like so you can spot what isn’t.
You don’t need a massive security overhaul. Just treat the pipeline like what it really is: a privileged actor that runs 24/7, doesn’t get tired, and never calls in sick.
One Last Thing, CTO to CTO
If you’re moving fast (and who isn’t?), your CI/CD is one of the most powerful systems in your company.
It’s not “just engineering.”
It’s not “just dev tools.”
It’s infrastructure.
It’s production.
It’s a security boundary.
If you’re not wrapping IAM around it—tight—you’re leaving a backdoor wide open.
And the faster your team ships, the more important it is to make sure the thing doing the shipping isn’t also the thing getting owned.
Because “just deploy it” is great.
Until the wrong person does.
