It's not you, it's me: Separating security from cloud

A quick note before we dive in: The journey I’m describing here is a personal one, synthesising lessons, stories, and observations from my entire career. Think of this as a “greatest hits” of hard-won lessons, not a diary entry about any single company, past or present. It’s all about the evolution of the practice (and the practitioner!).

I used to believe that there were 3 main pillars in DevOps. In my mind, DevOps, SRE and DevSecOps all belonged under one massive “platform” banner. We were all pulling in the same direction, using the same tools, breaking down silos to deliver value faster.

I no longer think this is the case - DevSecOps should be a standalone function away from Cloud.

It sounds counterintuitive. Surely if we want to shift security left and bake it in, we should be as close to Cloud as possible?

Yes, we should be close. But we cannot be roommates. While we share a mission - successful software - we have very different north stars.

Incentive Mismatch: Velocity vs Risk

Depending on the management structure and how the business you’re working in is ordered, you can have very different KPIs. Since Cloud contains the 3 pillars, usually the primary management figure is a cloud-focused person. This means they have clear KPIs in their mind - velocity, adoption, and realised value. They are measured by how fast features ship, how easily developers can spin up resources, and the stability of the production environment.

When security sits in this room as a subordinate function, our voice inherently gets dampened.

If the goal is “ship the new developer environments by Q3”, security often starts to look like a blocker. We become the drag on the parachute. Even a well-meaning cloud lead, when forced to choose between “shipping the feature” (realised value) and “refactoring IAM role” (future investment), will naturally bias towards the former.

DevSecOps gets wrapped into the mission of developer experience (DevEx). Don’t get me wrong, developers are our main customers - we must care about DevEx.

But we also have an ethical duty to find the cracks. Our loyalty isn’t exclusively to the developer - it is to the customer’s data. Sometimes, protecting that data means making the developer’s life slightly more inconvenient. If we directly report to the person accelerating developer experience, that necessary friction is often smoothed away before it can do its job.

The Cloud Constraint

There is also a difference in how we view the world.

Platform teams live in the weeds of implementation - AWS instance types, Terraform version and container upgrades. They look at a problem and ask, how can we build this in the cloud?

DevSecOps needs to look above the cloud. We need to act as a governance layer, not just an implementation layer.

We need to ask: just because we can solve this this way, should we?

We need to move fast with consideration of cloud, but not be constrained by it. If we are a sub-department of cloud, we end up solving every risk within the constraints of the cloud tool, rather than challenging the architecture itself. Independence allows us to step back and assess risk, without the pressure of having to implement the fix by Friday.

The Loose Brick: Visible vs Invisible Value

Security is often a hard sell because when it works, nothing happens; boring is good.

I like to think of security like an office building.

Everyone understands the visible security. You have keycards to get in, a receptionist at the front desk, and gates before the entrance. In our world, these are the CI pipeline checks, our WAFs, and our vulnerability scanners. It is easy to align with the cloud team on these because they are visible, measurable, and often automated.

But there is another side: structural integrity.

Imagine you notice there is a loose brick above the main entrance. It hasn’t fallen yet. It might not fall for a year, but it’s loose.

You could look at that brick and say, “fixing that costs money. I’d rather use that money to expand the office and hire more engineers”.

As security professionals, it’s our job to stare at that brick and say, “If we don’t fix this, and it falls, we don’t just lose money; we hurt someone.”

This is the invisible value of DevSecOps. We are the ones arguing for the maintenance of the building while everyone else is arguing for its expansion. If we sit under the cloud banner, our voice is potentially drowned out by the noise of expansion.

We need to be independent enough to articulate the cost of the loose brick.

Independence != Isolation

I’m not advocating for the silos to be rebuilt, the walls that we’ve spent years working to tear down. That is not the goal of DevSecOps - quite the opposite.

Security is a team sport; without engineering, we wouldn’t have a day job!

We should still work with cloud. We should still have an open-door policy, which I wrote about before. We should still use the same tools and repos.

But we collaborate as peers, not subordinates.

By separating the reporting lines, we create a partnership of equals. It allows DevSecOps to serve its own agenda - managing risk while maintaining developer velocity - with the same speed and autonomy that the cloud team serves theirs.

Healthy Friction

Ultimately, this comes down to healthy friction.

You want the cloud team pressing the accelerator. You want them pushing for speed, scale, and feature delivery. That is their job.

But you also need someone checking the brakes and watching the road ahead.

If one side dominates, the system fails. If security dominates, you get bureaucracy and stagnation. If cloud dominates, you get speed - right up until the moment you crash.

By separating the teams, we ensure both voices are heard equally. We create a system of checks and balances where the friction between “go fast” and “be safe” results in a better, more resilient platform.

So to my friends in cloud - it’s not you, it’s me.

You want to stay up all night shipping features and tearing down walls to build extensions. I want to walk around checking the locks and worrying about the loose bricks.

When we live together, we just drive each other crazy.

We can still be best friends. We can still build amazing things together. But I think our relationship - and the building - will be a lot healthier if I finally get my own place.