“According to Gartner® survey data, there is a 27% improvement to security outcomes when there is a high-level of collaboration between developers and security. However, only 29% of those surveyed say the two groups strongly agree with each other.” – Gartner, DevSecOps Maturity Model for Secure Software Development, 29 August 2024
In my last blog post on DevSecOps, I discussed an informal, internally developed maturity model for DevSecOps and posited that “DevSecOps represents the reality that DevOps must grow to encompass security.” The quote above by Gartner highlights the importance of making this shift. We know that better security outcomes are possible, but security and development teams are often on completely different pages. But the question is – how do we get there from here?
If we agree DevSecOps is the necessary evolution of DevOps, then we need to look back at DevOps. What was DevOps? It was as massive change in the culture of application development. Therefore, DevSecOps is the continued merging of organizational cultures that began with DevOps.
So again – why is this so difficult, and how do we get there from here?
AppSec is From Mars – Developers Are From… Mercury?
The proposed culture merger between security and DevOps is particularly thorny because of the environments that these groups of people generally come from. Again, we emphasize groups of people because moving to DevSecOps is fundamentally a human issue.
Developers and DevOps teams live in the IDE. They (should) have big chunks of uninterrupted “maker time” (to borrow from Paul Graham’s 2009 essay). Their job is to “move fast and break things.” Get to minimum viable product. Get feedback. Iterate. Produce!
Security comes from a different place. Whereas DevOps teams are told to move fast and break things, the goal of security is to never ever let anything break! They are bombarded by alerts that interrupt work.
So, when Gartner says “only 29% of those surveyed say the two groups strongly agree with each other” – this, I believe, comes down to culture and measurement.
The key to changing culture is in understanding the fundamental mindset of these teams and getting them aligned, and we’ve come up with five requirements to keep in mind when pushing internal change.
If you’re familiar with DevOps, you’ve likely heard of Jez Humble’s (co-author of The DevOps Handbook) CALMS framework. CALMS refers to the five proposed pillars of DevOps:
- Collaboration/Culture
- Automation
- Lean
- Measurement
- Sharing
We have come up with five requirements, aligned to CALMS, that will help move the needle on culture from DevOps to DevSecOps:
- Integrations
- Shared measurements
- Security education
- Security velocity that matches DevOps
- Automating security processes
We’ll be covering each of these five requirements in an upcoming series of short blog posts; but you’ll notice that the goal of each requirement is to start aligning teams with the needs of the others:
- Integrations get security teams thinking about how developers work, and how to keep them productive.
- Building shared measurements gets teams aligned on their goals so that they begin to have a shared language and outcomes they can agree on.
- Security education helps developers understand security, while also building their own skillsets; helping build careers and making security tasks faster and more efficient.
- Matching security velocity to DevOps helps developers feel like security is part of the process rather than a roadblock to it.
- Automations are the core of DevOps and make everyone happier and work more efficiently!
So again – Step 1 to getting on the road to DevSecOps is building commonality between your teams. Without common goals, and without demonstrating that each group is starting to care about the others’ needs, you’ll never properly address the human issues at the core of DevSecOps.
Our next blog will dive deeper into integrations, and how you can use them to build DevSecOps culture. But if you can’t wait for our next blog – we’ve got a special treat for you! In this blog we quoted a fantastic report from Gartner that includes their own formal, highly detailed maturity model, complete with five dimensions, each addressing what they consider to be a separate domain of DevSecOps. We like the Gartner report so much, that we’d like to offer our readers complimentary access. Please access the report, on us.
There are two sections in particular that I’d like to highlight here to help you change your organization’s culture – and they aren’t the maturity model. They are the fully detailed descriptions of a DevSecOps Community of Practice and DevSecOps enabling teams. Below we’ll discuss each of these recommendations and give examples of how Checkmarx has seen these to be highly effective in our customer organizations.
DevSecOps Communities of Practice
“While software engineering leaders can pursue many of the maturity improvements in this model alone, reaching a desired maturity state requires collaboration with the rest of the technology organization. A CoP can cooperatively drive an implementation strategy between departments.” – Gartner, DevSecOps Maturity Model for Secure Software Development, 29 August 2024
Based on our real-world experience working with customers, Checkmarx can easily validate this experience. We have worked with hundreds of organizations at different levels of maturity, and some excellent AppSec practitioners and organizations. However, time and again we have seen that no matter the quality of the AppSec team, they cannot truly succeed in meeting the needs of a DevOps organization without the buy-in of and collaboration with other functions within the organization.
Going back to our own maturity model, we have seen many excellent AppSec teams stuck at the bottom of this model. Gartner recommends building a Community of Practice out of five key domains:
- Cybersecurity
- Software Engineering
- Infrastructure and Operations
- Platform Engineering
- Business Units
Gartner gives excellent advice in the report on how to create and operate a Community of Practice within these teams. We recommend reading the details and urge you to remember what we have already covered – these teams must build common goals. Getting representatives from five different organizations in the room does not guarantee success. Remember that DevSecOps is about taking the needs and outcomes of security – risk management and mitigation – and integrating them into the process and culture of DevOps. If that is not the shared goal of everyone in your Community of Practice, the effort will fail.
DevSecOps Enabling Teams
“An enabling team’s purpose is to help trailing teams upskill and onboard to new tools and knowledge.” – Gartner, DevSecOps Maturity Model for Secure Software Development, 29 August 2024
This is fantastic advice and goes along with the industry’s push towards Security Champions. We’ve seen this put into practice at some of our more advanced customers. The goal is to create a small group of security experts and have them work with other development teams as coaches and mentors with regards to security. This pairs well with ASPM, where your security team is able to analyze vulnerability data to identify which development teams are most in need of support from security experts. Enabling teams can then be sent to mentor, support, and help those teams to uplevel their skills and more regularly write more secure code. We highly recommend finding senior developers with an interest in (or prior knowledge of) security to take on this role. Checkmarx worked with a major Western European broadcast customer where the security champion program was actually started by a developer (vs. AppSec). They went on to build a small, successful program that partnered closely with the AppSec teams to raise security awareness across the organization.
If they can do it, so can you!
Thanks again for taking time here today! This blog is the second in our series on DevSecOps. Our next blog will focus on using integrations to build DevSecOps culture. In the meantime, please don’t forget to read the Gartner report: DevSecOps Maturity Model for Secure Software Development.
GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.