Karl Fischer, CTO at Obsidian Systems.
For years, DevSecOps was treated as a sign that engineering and security were beginning to co-operate a little better than before. It was often presented either as process work or a more elegant way of structuring delivery. Thanks to AI, we have now entered a different phase.
AI is not only helping teams write code faster but also changing the economics of finding flaws, chaining exploits and probing software at a scale that was previously impractical. The issue is no longer whether attackers will use AI in meaningful ways but whether our software delivery practices are built for a world in which they already are.
This makes DevSecOps a critical component for business survival. What worries me is how fragile our environments have become. Too many organisations still build software on top of disconnected tooling, inconsistent controls and pipelines that were designed for speed first and scrutiny later. Security often enters late, with visibility across the development life cycle being too fragmented to be effective.
The software supply chain risk is no longer a specialist problem. It has become a board-level resilience issue. If an advanced model can help identify weaknesses across operating systems, browsers, open source components and infrastructure software faster than traditional methods, then traditional methods need to be left in the past.
The attack surface is no longer just the production environment. It is the repository, the build process, the dependency chain, the service account, the token, the developer workstation and the piece of open source code nobody thought to question because it had been used safely for years.
In a mature DevSecOps environment, security is embedded into how code is written, tested, packaged, deployed and observed. It shows up in identity governance, least privilege, secrets management, dependency scanning, policy enforcement, change control and automated validation. It reduces the space in which a mistake can hide and the time it takes to respond when one is found.
That matters because AI compresses the time needed to generate code, to analyse systems and potentially to uncover weaknesses. If your security model still relies on human bottlenecks, manual review and fragmented visibility, you are playing a slower game than the threat environment now demands.
This is especially relevant in South Africa. Many organisations here are balancing digital transformation with limited budgets, a lack of specialised skills, complex legacy environments and rising compliance expectations. Under those conditions, there is always a temptation to treat security as something that can be layered on later. When resources are tight, the argument for integrated security becomes stronger, not weaker. Incident response, downtime and reputational damage cost more.
DevSecOps does not eliminate risk. Nothing does. But it replaces blind spots with telemetry and one-off checks with repeatable controls. It helps organisations move from hoping vulnerabilities will not matter to designing systems on the assumption that they eventually will.
It also forces a necessary change in leadership thinking. We can no longer separate delivery conversations from security conversations. If the business wants faster software release cycles, then it must also invest in the controls, automation and engineering discipline that make those cycles safe. If executives want AI-enabled productivity, they need to understand that the same forces accelerating development are accelerating exploitation.
DevSecOps is no longer about best practices or organisational maturity. It is about whether your software delivery model is fit for an environment where AI can expose weaknesses faster than many teams can govern it. In that world, security cannot be adjacent to development. It has to be part of how development works.
