If Your Security Strategy Relies on the Business, You Have No Strategy

We have all sat in those quarterly planning meetings. The executive team unveils a beautiful, colour-coded, 12-month product roadmap. It is logical. It is ambitious. But we all know that by week four, a major client will ask for something totally different, or a new tech trend will drop, and that roadmap will change radically.

If your DevSecOps strategy is entirely coupled to what the business is building - for example, “We will secure Feature X by May” - you are going to spend your entire year playing catch-up.

If your security strategy relies on the business knowing what it wants, you have no strategy.

The Whack-A-Mole Trap

The business should pivot. That is how it survives, adapts, and makes money. Getting angry at the sales team or the C-suite for changing direction is a waste of energy.

But when you don’t have an independent, underlying security strategy, you become purely reactive. When the business suddenly pivots to Kubernetes, you panic and buy a container scanner. When they pivot to AI, you scramble to write a restrictive LLM policy.

This reactive state turns security back into the “Department of No.” Because you weren’t prepared for the pivot, and your processes aren’t mature, your only available tool to buy time is to hit the brakes. You end up chasing tools to fix immediate symptoms, rather than addressing the underlying issues.

Enter DSOMM: A Compass, Not a Straitjacket

To survive the whiplash, you need a north star that remains constant regardless of what the business decides to sell tomorrow. For me, that is the DevSecOps Maturity Model (DSOMM).

There are other maturity models out there - like OWASP SAMM or BSIMM - but they often lean heavily into enterprise application security and overarching governance. They are heavy. DSOMM, however, is laser-focused on actual DevSecOps functions. It speaks the language of pipelines, automation, and engineering reality.

I am still early in my own journey with this. Adopting a maturity model is a marathon, not a sprint. I am actively using this framework today, still adapting it to fit our daily reality, and still figuring out how to make it work seamlessly without slowing anyone down.

I hate rigid, prescriptive frameworks. I do not use DSOMM as a stick to beat developers with, nor is it a massive compliance checklist. I use it as a compass to guide our processes.

DSOMM doesn’t care if you use Snyk, Mend, or an open-source CLI tool. It cares about dimensions of maturity. It asks: How mature is our build and deployment process? How mature is our defect management?

If you invest your time into maturing these underlying processes - automating your testing, standardising how secrets are handled, creating a culture of continuous threat modelling - it doesn’t matter what the business throws at you. The safety net is already there.

Testing the Compass: The Sudden Pivot

Let’s look at a potential real-world scenario. Suddenly, the CEO reads an article and demands LLM integration by Q3.

The reactive way to handle this is to panic, attempt to ban the tools, write a 40-page PDF policy, and block the deployment pipeline until a shiny new “AI security platform” is procured.

But let’s demystify this. I spend a significant amount of my own time experimenting with agentic workflows and local LLMs, and the reality is that within the context of the Software Development Life Cycle (SDLC), AI is just another tool.

Now, I am not naive. I know that defending infrastructure against autonomous, AI-driven attacks is a different, rapidly evolving beast. But when it comes to building and deploying applications that integrate LLMs, it is the exact same old story.

Whether it is a human engineer accidentally logging PII or an LLM hallucinating and leaking it, the consequence is identical. Unsanitised input from an AI prompt is just as dangerous as unsanitised input from a human user filling out a web form. The guardrails we need to mitigate these risks - strict access controls, data masking, and least-privilege architecture - are the exact same ones we already use for standard software.

This is why the DSOMM compass is so vital. You don’t need to invent a brand new “AI security strategy”.

Because you have already matured your secret management process, you know the API keys for the LLM won’t be exposed. Because you have a mature data privacy dimension, you already have controls preventing PII from hitting the logs. Because you have a mature threat modelling process, you simply grab the lead developers for 30 minutes to discuss prompt injection before they write the code.

The framework flexes to accommodate the tool. You aren’t building a new strategy from scratch - you are simply applying your mature processes to a new iteration of an old problem.

By framing it this way, you validate the executive’s desire to adopt AI, whilst simultaneously calming the security team’s panic.

The Shock Absorber

A good DevSecOps team acts as a shock absorber for the engineering organisation. We absorb the chaos of the business pivot so the developers can just focus on writing code safely.

You cannot secure a moving target. The business will always change its mind. But you can build a very safe, highly mature vehicle. Let the business change the destination - our job is to make sure the brakes, the seatbelts, and the lane-assist work flawlessly, no matter what road we are driving down.