Why DevSecOps remains a mirage

Despite the rhetoric around DevSecOps, security remains an afterthought when organizations are building software. Meanwhile, the latest Verizon threat report identified that web application attacks have doubled, validating that cloud-based data is under attack. The surge in web app security breaches in 2019 further solidifies that we are a long way from delivering on the DevSecOps vision.

With the rush to embrace digital services, organizations remain focused on the speed of release rather than on the quality of services. To accelerate the pace of digital transformation, security must be a fundamental part of software development.

To achieve DevSecOps, enterprises need to develop code faster and identify vulnerabilities sooner. Otherwise, you run the risk of DevOps, simply creating software with vulnerabilities more quickly.

So, how can organizations make DevSecOps a reality? It’s all about embedding security within all aspects of your software development process rather than having it as a clunky bolt-on at the end. Here are four recommendations on how to make that happen.

1. Security needs to shift earlier in the SDLC

Security must be part of each stage of your software development lifecycle (SDLC). Product managers need to ensure that requirements, epics, and user stories have security acceptance criteria. Technical architects need to ensure that designs are reviewed from a security perspective (ideally by a security expert). Project managers and scrum masters need to ensure that security is factored into estimates. Your definition-of-done needs to include security criteria and you must review every part of your SDLC and ensure security is being considered.

To do this requires a mindset shift from the obsession with software delivery speed to a focus on quality. Too many teams measure success only in terms of velocity and time-to-market; you need to have quality and security measures. Developers are still reluctant to think about security and must be reminded to consider the quality of the code they deliver. With the current focus on speed, too often, software is released that is not stable, has vulnerabilities, and is not ready for widespread adoption. The recent failures with Zoom are a great example of the rush to deliver innovative services with little thought about security vulnerabilities.

2. Break down the “security” monolith

Security is a broad area with different security issues such as authentication, access control, confidentiality, integrity, non-repudiation, and more. Different threat models range from simply making sure that an employee doesn’t accidentally do something they are not supposed to, to trying to protect data from state-sponsored cybercrime professionals. A single approach can’t possibly address all aspects of security or do it efficiently, yet that’s precisely what most teams try to do.

Instead, teams need to breakdown the security monolith into what it means to them and what matters to their users, e.g., keeping customers’ data confidential, ensuring customers only get access to the features they’ve paid for. They also need to define the threat model (i.e., the types of attacks) they need to defend against. If your product is deployed inside a corporate file, then denial-of-service attacks are unlikely to be an issue, but password theft attacks probably are.

3. Simple threat models have simple solutions

One of the security myths is that only a small number of highly specialized experts can “do security.” Now, this is true when it comes to designing architectures to protect data in distributed systems against highly skilled and determined attackers. But it’s absolutely not true if you’re just trying to ensure that your latest changes haven’t broken your existing authentication mechanism or that your authentication can’t be broken by random script kiddies.

Once you’ve broken down the “security” monolith, you can start addressing these different security issues in different ways. For example, a large number of threat models can be addressed using standard static and dynamic analysis tools. Sure, these tools won’t fix a flawed architecture or prevent attacks from highly skilled determined attackers, but they should deal with over 90 percent of threat models.

This is key to embedding security across your whole SDLC because it means that you don’t need an army of security specialists as most security issues can be dealt with by tools, developers, and testers. You only need your security experts for those big architectural reviews and periodic audits.

4. Security is everyone’s responsibility

Once you’ve broken down the “security” monolith, it’s much easier to get everyone involved in security, because you’re not asking everyone to become a security consultant, just learn enough to deal with over 90 percent of threats.

Of course, this doesn’t just come magically; you still need to train the team to understand the threat models you’re trying to protect against, the overall security architecture, and what they need to do. By breaking it down into threats and techniques, this training is far more useful than generic “security” training and will help ensure that your applications stay secure.

By applying these four recommendations, we believe that any organization can achieve a solid level of security and start making DevSecOps a reality. If organizations don’t rethink how they approach security as they develop software, then the number of web-based vulnerabilities will continue to grow.