DEVOPSdigest

The DevOps revolution of the past decade has been driven by an increasingly fast-moving world. Where once the release of new software and applications was an event that happened every few months, it's now a constant, ongoing process with new code rolled out continually. DevOps teams have embraced this challenge by breaking free of the traditional siloed approach, and owning more of the development cycle themselves, including quality testing, integration and deployment. However, there's a major component that DevOps is still failing to take responsibility for: security.

Previously in app development, developers' main role was to write code that performed a specific function, regardless of the quality of the end product — that was the QA team's responsibility, not theirs. The DevOps model arose out of a recognition that this way of working simply wasn't tenable anymore. Empowered by advances in cloud delivery, containerization and microservices, applications can now be created and deployed by the same team, without the need for constant hand-offs to other departments. This means that DevOps is now responsible for the quality of the end product — in terms of user experience, speed, resilience, etc — rather than just its functionality.

However, attitudes towards security are still stuck in the old way of thinking. While DevOps has taken on responsibilities that used to reside with other teams in order to make the non-stop cycle of software releases more efficient, there still seems to be a general belief that the security team remains responsible for protecting DevOps' products. There may be cultural and organizational reasons for this belief linked to the perceived power and centrality of the security team in many companies. But the fact remains that the DevOps revolution won't be complete until the security of products is also baked into the software development process.

In many ways, this is a no-brainer of a statement. If DevOps now owns product quality — in other words, making sure that application performance is optimal — then surely a big component of that is verifying upfront that code doesn't contain known bugs or backdoors which could impact its security. If you built a car that was perfect in every way except it had a tendency to catch fire at high speeds, you would quickly conclude that there was a major problem with the quality of its design. The same is true for a website that is easily hacked because not enough was done to protect its code. If your customers' bank details have been stolen, you can be sure you've got a quality problem.

Perhaps due to the overarching presence of the security team within the modern company's IT organization, right up to board level if a CSO has been appointed, DevOps may have been content in the past to sit back and let these guys "do their job." But with security being a major part of the product quality equation, this is no longer a sensible mindset to adopt. If the website or application you've launched gets hacked or becomes infected, DevOps will increasingly be held responsible for this failure rather than the security team. To say that DevOps shouldn't have to worry about how secure their code is because another team will catch that problem is analogous to disregarding the expense of a project just because there's a finance department.

Yet this isn't just about facing up to responsibilities. Rather than seeing the security aspect of software development as yet another burden on their shoulders, this is an opportunity for DevOps to further extend its authority and influence. Instead of waiting for tools and processes to be mandated by the security team, DevOps teams need to be more proactive in finding and selecting the solutions they need to write, configure and deploy secure code the first time. After all, DevOps are more likely to understand which would be the most useful tools to have in those initial code creation stages, and which would strengthen their ability to work in an agile fashion.

It's clear that in the past there have been issues with how the security function has been presented to developers and the wider company. There was a time when risks and threats to the enterprise and its online presence seemed to multiply exponentially, and companies were forced to respond by deploying ever more complex remedial products, such that IT security became its own discipline and an industry in itself. In this new and rather daunting world, there was often a sense among other IT stakeholders such as developers that security was too far outside of both their understanding and their remit.

However, we need to move on from those days. With the prevailing mantra that prevention is always better than remediation, and that security needs to adopt more "shift-left" practices to be truly effective, DevOps might be surprised to discover how receptive their security team is to sharing responsibility and working more collaboratively. While the security team may still oversee and have input into relevant parts of the DevOps process, they should no longer have to contend with code that hasn't been written with security in mind.

DevOps must regard security as a core facet of software quality and performance. There's definitive evidence of movement in this direction, particularly with the recent emergence of the so-called DevSecOp culture. Yet really, this is a misnomer, because "Sec" shouldn't have to be a separate element that's pulled out and highlighted within the DevOps process — rather, it should be totally integral to everything that DevOps does. But until that's the case, the DevOps revolution will remain incomplete.