What is DevSecOps? It involves taking all the practices of DevOps and pulling in security practices to improve security. Tom Stiehm (@thomasstiehm) explains the process.
In DevSecOps, we want to shift security left. Shifting left brings security into the application process earlier instead of allowing it to be an afterthought.
Shifting left lets us deal with security issues early and often. If we leave security practices to the end, we end up with security defects in production. So shifting left reduces risk and the costs of fixing security problems.
As with other bugs, finding and fixing security bugs earlier leads to fewer errors and fewer compromises.
Let’s next talk about how we can shift security left.
We start with proactive processes instead of reactive processes. Then we architect and design security early. Finally, we automate testing that focuses on security as well.
Security practice in DevSecOps from Tom Stiehm’s “Shifting Security Left: The Innovation of DevSecOps” presentation.
An important step is to also review the automated test results and remediate early. Without that step, we won’t be fixing problems before they hit production.
When looking at the model above, look at all the ways that you can bring security into every step. When planning, we can use threat analysis to figure out what our risks for the application are. Then when we write our code, we can use static analysis (SCA or SAST) to make sure we’re not introducing vulnerabilities like SQL injection. With SAST, we’re analyzing the code we’ve written for common vulnerabilities. On the other hand, with SCA, we’re looking for vulnerabilities in our dependencies like open-source libraries. The combination of SAST and SCA will help us determine if we have something that puts us at risk.
Next we’ll look at DAST and IAST. DAST provides dynamic testing against your running application. One problem with that seems to be a number of false positives. IAST uses an interactive model that watches your software to see if someone is currently attacking your system. It’s been shown to have fewer false positives than DAST.
Another great tool is pen testing. This can be automated or manual testing against your running system.
For your production system, tools like RASP and SIEM can provide additional views of security.
Again, with all these tools the focus is on bringing security into the whole development lifecycle.
Secure practices in a pipeline from Tom Stiehm’s “Shifting Security Left: The Innovation of DevSecOps” presentation.
When looking at the DevOps pipeline, you can see how these tools can fit in throughout the process. As you can see, we’ve got a number of places where we’re pulling security in. This is more thorough and reduces risk compared to the old model where we did security testing and analysis last.
So where should we begin? Starting with SCA provides a lot of benefit. Many vulnerabilities have been found and exploited because of open-sourced dependencies. Because teams don’t always know their dependencies are vulnerable, they often have delays in getting the dependencies patched or upgraded.
The next step would be using SAST. It’s quick to integrate in the build pipeline and provides benefits for the code your team writes.
And third, we can start looking at DAST. It’s a bit more involved, but it’s becoming more automated and easier to integrate into your pipeline.
Going back to the shifting left, let’s talk about the culture shift. The culture shift should build the mindset that “everyone is responsible for security.”
Part of that includes building a knowledge base. Encourage people to talk about how to deal with security challenges. Work with your security professionals to share that knowledge between teams. Figure out what lessons teams can learn from each other.
Each organization is different. We have different processes and different tools. Start doing things that work and stop doing things that don’t work for your particular organization
Starting to shift left is more important than which practices you start with. Write security requirements and make sure that you have tests that verify your security requirements are covered. And make iterative changes to improve the process.
Sylvia Fronczak is a software developer that has worked in various industries with various software methodologies. She’s currently focused on design practices that the whole team can own, understand, and evolve over time.
Originally published on the Sonatype blog.
Photo by Nick Fewings