DevSecOps: Where Are We Now?
DevOps represents the fundamental cultural shift in software engineering towards performance: high performing teams, and high performance code.
In DevOps, security was never a primary consideration.
DevSecOps represents the reality that DevOps must grow to encompass security. Eventually, performant code will mean secure code by default – but we’re not there yet. How do we get there?
Let’s start with where we are now. Earlier this year, Checkmarx ran a survey asking CISOs about their current AppSec programs. One of our questions specifically asked: “Where are you on your DevSecOps journey?” You can see the answers below:
On the surface, this doesn’t look too bad… until you consider the details. Based on our scaling, “medium” only represents the “definition and strategy” phase. The actual process of integration and automation is where companies actually start “doing” DevSecOps, and only 1 in 5 companies surveyed have reached that stage in some form.
And let’s be clear – integration and automation are the goals of DevSecOps. DevSecOps is about taking the needs and outcomes of application security and integrating them with the processes and culture of DevOps. In 10 years, there should be no difference between “DevOps” and “DevSecOps.” DevSecOps is just what DevOps needs to be when it grows up.
DevSecOps: The Path to Maturity
OK –how do we get there? If I were to create a rough sketch of DevSecOps maturity, it would look like this:
Let’s start on the bottom. This is traditionally where AppSec finds vulnerabilities, and essentially throws them over the wall to developers and says “here, fix these.” I have some bad news for you, this is actually “Shift Left” in action. Maybe that’s flippant and a bit unfair; but it is the base level of maturity that puts organizations on the road to DevSecOps.
The next level focuses on the developer experience. Here, AppSec teams and developers alike realize that “Shift Left” isn’t really working. Not because anyone is bad, uncaring, or unintelligent, but because it is only intended to be the first step. In that stage, AppSec got tools to find and triage vulnerabilities. Now developers need tools to manage those vulnerabilities themselves without breaking their workflow. The “developer experience” stage of maturity focuses on IDE-integrations, remediation guidance, and other ways to keep developers focused without greatly disrupting their flow.
But like “Shift Left”, focusing on the developer experience eventually hits diminishing returns. Organizations will get stuck, and then they will need to begin to move towards the third step of maturity. This is where you take the foundational understandings of the first two steps, and work to define a DevSecOps culture.
DevSecOps: Worth the Effort
Culture is hard to change, but luckily, DevOps people have done it before. If you go back to the early days of Agile and Scrum, teams would hold daily standups, and then go back to working exactly the way
they had before. But, as modern DevOps organizations can confirm, it’s worth the effort. For DevSecOps, it’s also worth the effort. Here is an example of a Checkmarx customer’s journey, and you can see them go through the stages and the results:
This is a chart showing the number of vulnerabilities remediated by a Fortune 100 company, and it’s a powerful representation of what things look like when teams integrate.
If you’re curious about the types of things this customer did to get from the left to right side of the graph above, here we’ve got some examples ready based on where you are from a maturity standpoint:
- Shift Left: If you just need to get something in place to start getting vulnerabilities over to developers, the easiest way is to integrate your AppSec tools with your feedback tool (be careful here, you don’t want to suddenly shunt 10,000 JIRA tickets over to the devs, so set some policies around it). Click here to see a video showing how easy that the integration is to do with Checkmarx.
- Developer Experience: The easiest way to start improving your developer experience is by integrating with their IDE of choice. This is also simple to do with Checkmarx, and here is a video showing how: Watch now!
- DevSecOps: We’ll explore the keys to DevSecOps in detail in the next blog, particularly culture, automation, and speed, but we mentioned the importance of policy management in our first bullet point. While designing policy is difficult – it relies on great communication between development teams and security teams – creating and implementing policy with Checkmarx is easy. Here’s a video showing how it’s done: Watch now!
This blog is just our first in a series on DevSecOps. Our next blog will focus on how to change culture, the need for automation, and the true meaning of “speed” within the context of DevSecOps. In the meantime, the videos I just listed are only some a few of those you can check out over on YouTube
showing how easy it is for platform engineers and developers to integrate and work with Checkmarx One. Check them out!