If you’ve been involved in IT for a while you have been aware of the term DevOps; you may even have such a group in your own organisation. Recently, a new term has been coined, that of Secure DevOps or SecDevOps and it has joined the IT security landscape.

Both are somewhat misleading terms. DevOps was originally coined to describe the union of in-house software development teams and IT operations. If IT operations teams could assist with, and thus speed the development of software for the wider business benefit of the company, then it had to be a good thing. As a practice it then got lumped in with the very cool sounding Agile Operations: fast, efficient and responsive.

Alas, cool sounding concepts don’t always deliver the business benefits they promise. DevOps has matured, if that is the right word, to be many things to different organisations, and with digital transformation underway, its role, or significance to the organisation, is changing again.

If DevOps had remained as a genuine, and simple, collaboration between IT and software development teams, driven by the needs of the business, it would be a very good thing. It would be even better if this cooperation remained throughout the application lifecycle form design right through to support. And even better than that, security would also be factored in from the outset – but we will come to that.

What has happened recently is that DevOps has become all Dev and not much Ops. Cloud based applications, apis and web apps are being developed on the fly with little thought for existing infrastructure and operations. Ironically the growth of unregulated and insecure software development has been exacerbated from pressure by business teams eager to press on with digital transformation. To complicate matters further, DevOps now includes those lines of business buying or even developing untested and unsupported applications as they wish, and putting them into the hands of employees, customers and partners.

Inevitably this state of affairs has resulted in the growth of Secure DevOps, with vendors now promising that they can take the risk out of unregulated and unplanned devops.

But with something so wide ranging and hard to define it is hard to know what to secure, when or how in the application lifecycle. The simple truth is that DevOps is insecure because developers and the IT teams are under pressure from businesses to create and implement software, APIs and other applications a fast as possible.

Inevitable flaws will remain in the code that is put live, and hackers can, and do, find and exploit those vulnerabilities to steal data or insert malware.

It is this that needs attention, it’s not secure DevOps that is needed but secure code development. Crack that and it doesn’t then matter how you define the DevOps team in your organisation, as long as you have a security layer between actual software code development and the infrastructure on which it is to finally operate. This can be a vendor or MSSP choice or a new layer created within the business, but application security must be a responsibility in its own right, not dependent on either code writers or operations people.

In other words let’s welcome the rise of DevSecOps – in that order!

Calling something secure doesn’t make it secure unless it is designed in.