From DevOps to DevSecOps: Why I Started Breaking Things on Purpose

I’ve been a DevOps engineer for a long time. Nearly two decades, if you count the years before we called it DevOps. Back when it was just “the infrastructure guy” or “the Linux admin” or “the person who knows what Terraform does.”

I built CI/CD pipelines. I wrote Ansible playbooks. I argued about Kubernetes cluster topology. I was good at it. Comfortable.

And then I started reading breach reports at 2 AM.

The Night Everything Changed

It was March of last year. I couldn’t sleep. I’d had coffee too late in the afternoon and my brain was spinning.

I found myself on Hacker News, reading about a company that had lost customer data. Not a breach — a misconfiguration. An S3 bucket. Public read access. Millions of records.

“That could never happen to us,” I thought. “We have policies. We check these things.”

But I couldn’t shake it. I got up. Opened my laptop. Started checking.

Four hours later, I found three public S3 buckets. None of them had customer data, thankfully. But they had logs. Config files. Enough information for an attacker to map our infrastructure.

I fixed them. Wrote an incident report. Told the team.

And then I couldn’t stop.

The Shift

I started spending my nights differently. Instead of reading about new Terraform providers or Kubernetes operators, I was reading about:

• JWT vulnerabilities
• SQL injection techniques that still work in 2026
• How to bypass CORS
• What trust proxy actually does in Express

I started looking at our code differently. Every endpoint was a question: “What if someone sends weird input?”

Every configuration was a suspicion: “Is this actually secure, or does it just look secure?”

I started running curl commands against our staging environment at odd hours. Creating test invoices. Seeing what error messages revealed. Mapping out what endpoints existed.

I was becoming… paranoid.

But in a good way.

Why Not Just Use Tools?

People ask me why I do this manually. Why not use Burp Suite? Or OWASP ZAP? Or one of the enterprise scanners?

I do use those tools. They’re great. But they find the things they’re programmed to find.

What I find manually is different:

• The CORS misconfiguration that accepts any subdomain
• The scientific notation that creates million-dollar invoices
• The internal fields that shouldn’t be updatable but are
• The webhook that accepts anything because validation happens async

These aren’t in the CVE database. They don’t match standard patterns. They’re the result of how our specific code works.

You need a human to find those. A human with coffee, insomnia, and a terminal.

The DevOps to DevSecOps Transition

Making the official shift to DevSecOps wasn’t a single moment. It was gradual.

First, I started including security checks in my Terraform modules. Automated S3 bucket policy validation. IAM policy scanning.

Then, I started doing pre-deployment security reviews. Not formal audits — just “let me look at this endpoint before it goes live.”

Then, I found that critical vulnerability. The one that would have let anyone create invoices. That’s when the team realized: “Okay, this needs to be a formal part of our process.”

Now, I’m the person who:

• Reviews new endpoints for auth issues
• Checks input validation logic
• Runs fuzzing tests before releases
• Writes security documentation
• Panics at 3 AM about configurations

It’s a different job. Same skills, different focus.

What I Learned

1. Developers Trust Too Much

Not in a malicious way. They trust that:

• DTOs will protect them
• Frameworks handle security
• Users will send reasonable input
• “It works” means “it’s secure”

None of these are true.

2. Infrastructure and Application Security Are the Same Thing

You can’t secure the app without securing the infrastructure. You can’t secure the infrastructure without understanding the app.

That ALB security group misconfiguration? That allowed the X-Forwarded-For bypass. Infrastructure problem that became an application vulnerability.

3. Paranoia Is a Feature

I used to think being paranoid about security was a character flaw. Now I think it’s a job requirement.

Assume everything is broken until proven otherwise. Trust no input. Verify every configuration.

4. Documentation Is Security

The most secure system is one where the next person can understand what you built and why. Undocumented magic becomes undocumented vulnerability.

I write more docs now than ever. Not because I like it (I don’t), but because it’s the only way to maintain security over time.

The Tools I Use

I said I do most of this manually, and I do. But I also use tools:

For infrastructure:

• checkov — Terraform security scanning
• tfsec — Another Terraform scanner
• AWS Config rules — Continuous compliance checking

For applications:

• curl — Still the best testing tool
• jq — JSON manipulation and analysis
• Custom scripts — For specific tests I run repeatedly

For monitoring:

• CloudTrail logs — Watching for weird API calls
• Application logs — Looking for error patterns
• Custom alerts — For things that shouldn’t happen

The Mindset Shift

The biggest change wasn’t technical. It was mental.

As a DevOps engineer, my goal was: “Make it work. Make it reliable. Make it scalable.”

As a DevSecOps engineer, my goal is: “Make it work. Make it reliable. Make it scalable. And make sure an attacker can’t abuse it.”

That last part changes everything.

You start thinking about:

• What happens if this endpoint is called 1000 times per second?
• What happens if someone sends a 10MB JSON payload?
• What happens if the database connection fails mid-transaction?
• What happens if someone sets isDeleted: true on their own account?

Edge cases become primary concerns. Failure modes become features.

Advice for DevOps Engineers Making the Shift

If you’re reading this and thinking “I should do more security,” here’s what I’d tell you:

1. Start with your own code

Look at the last endpoint you built. Ask:

• What happens if I send it garbage?
• What happens if I send it nothing?
• What happens if I send it too much?

2. Learn one attack vector deeply

Don’t try to learn everything. Pick one:

• SQL injection
• XSS
• Mass assignment
• Authentication bypass

Learn it well enough to spot it in the wild.

3. Read breach reports

Not the sensational ones. The detailed ones. The post-mortems. Understand how real attacks happen.

4. Break something (in staging)

Find a vulnerability. Exploit it responsibly. See how it feels.

That feeling — the mix of excitement and dread — is how you know you’re thinking like an attacker.

5. Talk about it

Security isn’t a solo sport. Share what you find. Teach your team. Make security part of the culture.

Why I Keep Doing This

It’s exhausting sometimes. The 3 AM discoveries. The emergency fixes. The Slack messages that start with “so I found something…”

But it’s also incredibly satisfying.

Every vulnerability I find before an attacker does is a win. Every config I secure is a potential breach prevented. Every developer I teach is a multiplier.

And there’s something deeply gratifying about understanding systems well enough to break them. To see the cracks that others miss.

Plus, I get to write blog posts about it. Which is nice.

What’s Next

I’m not stopping. The landscape keeps changing. New frameworks, new vulnerabilities, new attack vectors.

AI is generating exploit scripts now. That means:

• Attackers can move faster
• More people can exploit systems
• The baseline for security is rising

Which means I need to keep learning. Keep testing. Keep breaking things on purpose so they don’t get broken by someone else.

If you’re a DevOps engineer reading this, consider making the shift. The world needs more people who understand both infrastructure and security.

The paranoia helps.

---

If you’re on a similar journey, or thinking about starting one, I’d love to hear from you. LinkedIn or GitHub. Let’s be paranoid together.