I recently wrote about the reasons why security and DevOps should coexist, as discussed on a panel of technology leaders at the SINET Innovation Summit in New York.
One of these reasons is that secure DevOps is a mindset and a shared responsibility. Everyone in the organization, including architects, developers, QA, DevOps and security teams, has an important role to play in the process of shipping secure software.
What is that mindset and how should companies adopt it?
It is now well accepted that security needs to be “shifted left,” i.e., incorporated during the earliest phases of the modern software development lifecycle (SDLC) and cloud deployments.
But how to do it still isn’t clear. With each security vendor touting how its product fits into DevOps, it might seem that if we took enough security products and inserted them into DevOps, we would have achieved the goal. Many companies have tried this strategy and failed. What’s going wrong?
We should learn from the success of DevOps. DevOps is about the mindset. It is a process where the entire team works together to achieve an agile SDLC (Figure 1).
Figure 1: The DevOps Process
The DevOps mindset then becomes one for releasing and managing applications securely. Each stage is owned by a different persona who have their unique insights. The security goal is to leverage each person’s expertise to enhance security without slowing them down.
Mindsets By Stage
In the “plan” stage of the process, the architects establish requirements, such as encryption and data handled by each microservice. For example, if the application handles highly sensitive data, the security requirements should be elevated to “high” — meaning “no critical or high vulnerabilities.” Or, if a required encryption cipher is not being used for certain data types, “fail the build.” Once these requirements are established, the discussed checks should be performed continuously for every build.
Developers own the “code” and “build” phases. This is the perfect place to allow them to ask questions like: Am I using an open source library that makes my application vulnerable? Am I encrypting all the important data that my code is dealing with? Are there any vulnerabilities in my code?
The key is to accomplish this with high fidelity within minutes of each build. If not, security becomes a burden — and is abandoned. Done right, this saves developers time and makes them more agile, which is the reverse of the prevailing notion about application security (AppSec).
Unique security insights can be revealed in the “test” and “release” stages because these are the first stages where the entire application is being subjected to test traffic. Questions such as: How much test coverage am I getting from my QA testing? In a microservice architecture: How do I ensure that security is end-to-end and not just for one microservice? And, if you use production traffic in QA: Which of the vulnerabilities see the most traffic so I can prioritize based on the probability that they can be exploited in production?
Traditionally, “deploy,” “monitor” and “operate” stages are the places where most security tools are deployed. These tools should not disrupt the DevOps process, but should be effective and efficient at protecting the applications. The tools also should not require each customer to do a lot of work to tune them to their environment. Instead, the agility of the DevOps process demands that the security tools deliver application-specific security, specific to each version of each application. This eliminates inefficiencies like policy tuning and false positives and minimizes performance impact on the applications.
Inserting security into DevOps is a shared responsibility where each person has a crucial role to play depending on the stage of the DevOps process they own. Following this blueprint on how to shift security “left” will help organizations succeed in the new world where the only way to beat the competition is to deliver new functionality to your customers faster and securely.