Here’s a decision every organisation makes, usually without noticing it made one: where does security live?
It can live at the gate — a checkpoint near the end, owned by a team whose job is to say yes or no before something ships. Or it can live in the loop — continuously, in the hands of the people building the thing, as an ongoing property of the work rather than a stage of it. That’s a genuine architectural choice, with genuine trade-offs, and almost every argument about DevOps, SecOps and DevSecOps is really an argument about where on that spectrum you’ve landed — and whether you did it on purpose.
Because that’s the thing about those three words: they get used as if they’re rival products or interchangeable job titles. They’re not. They’re three answers, given in three different eras, to the same question about where work lives and who’s on the hook when it breaks.
Three answers to one question
DevOps was an answer about operations. Developers wrote code and threw it over a wall to the people who ran it; the two groups had opposing incentives — devs rewarded for change, ops for stability — and the wall between them was where delivery went to die. DevOps moved operational concern off the gate and into the loop: same team, shared ownership, and the people who build a thing also feel it run at 3am.
SecOps — security operations — is the detect-and-respond world: monitoring, alerting, the SOC, incident response. Crucially, some security work genuinely belongs at a gate, or at least in a dedicated pair of hands. You do not want incident response to be a thing everyone does a bit of. So SecOps isn’t the villain of this story; it’s the acknowledgement that a slice of security is a specialism, not a shared chore.
DevSecOps is the same move DevOps made, applied to the rest of security — the part that was sitting uselessly at the gate. The review you fail the week before launch. The pen test that comes back with a list you’ve no time to fix, describing a design decision you made six months ago and welded into everything since. DevSecOps takes that work off the wall and puts it in the loop, where it’s cheap to act on.
What the three have in common
Line them up and the shape is identical. Every one is an argument about where the feedback loop closes and who owns the outcome.
The gate model pushes the feedback as far from the builder as it can go. You learn your code is slow when ops complain in production. You learn it’s insecure when the annual pen test lands. The feedback existed — it just arrived too late, and at the wrong desk, to be anything but expensive. Move the loop’s closing point next to the person who can act on it — a leaked secret flagged in seconds, a vulnerable dependency caught on the pull request — and the same finding costs a fraction to fix. That’s the entire game. Everything else is tooling.
Shift the feedback left, not the blame
The slogan for this is “shift left” — move the work earlier. It’s right. But there’s a cheap version and an expensive version, and they look identical on a slide.
The cheap version shifts the blame left. You keep the same late, adversarial gate and simply start pointing at developers when it catches something. “Security is everyone’s job” quietly becomes “it’s your fault now, and still my job to tell you off about it.” No loop has moved; the misery has just been redistributed.
The expensive-to-build, cheap-to-run version shifts the feedback left. It puts fast, automated, low-friction checks into the loop the developer is already in — the editor, the pull request, the build — so the signal arrives while the context is still warm and the fix is still small. The developer doesn’t have to become a security expert. The secure path just has to become the path of least resistance.
It’s a Conway’s Law problem wearing a hoodie
If you’ve read what happens when org shape leaks into system shape, you’ll recognise the deeper tension here. A separate team that owns security tends to produce a system where security is separate — a bolt-on, a gate, a thing that happens to the software rather than in it. The reporting line becomes the architecture. The org chart wins; it always wins.
Which is why “let’s adopt DevSecOps” can’t be bought. You can wire the best scanners in the world into a pipeline, but if security is still someone else’s KPI, the feedback still closes on the wrong desk. Tooling is necessary and nowhere near sufficient. The decision that actually moves the needle is an organisational one about where the work lives — and that’s a far more uncomfortable thing to change than a CI config.
The question this leaves open
So: push security off the gate and into the loop. Right move. But it smuggles in a question the DevSecOps sales deck would really rather you didn’t ask — how much? If security is continuous and it’s everyone’s job and every check you can automate you should, where does it stop? You can add controls forever, and each one has a cost. At some point the next control makes the system worse, not safer.
Which is the giveaway that security was never something you maximise. It’s something you optimise — and optimising means being honest about what you’re trading away. That’s where this little series goes next: how much security is too much, and then how you’d put an actual number on the answer.
Strip the branding off all three words and the same unglamorous idea is left standing. Move the feedback next to the person who can act on it, and make owning the outcome cheaper than dodging it. Everything else is an argument about where you drew the line — and whether you can say why.