To Succeed, DevSecOps Must Actually Include DevOps

*Note: Join us live and online for the 2019 Nexus User Conference on June 12. Registration is free.

Before implementing any DevSecOps tools, you have to embrace that DevSecOps is disruptive to the entire security tool landscape. Too many tools are just lipstick on a pig.

But how do you know which ones are lipstick and which ones transform the pig from the inside out? Larry Maccherone laid this out in his talk at our Nexus User Conference. If you're not already familiar with Larry, he is an industry-recognized thought leader on DevSecOps, Lean/Agile, and Analytics and currently leads the DevSecOps transformation at Comcast. In other words, he knows what he's talking about. 

The problem in the DevSecOps landscape today is that people are labeling “traditional tools” DevSecOps without any DevOps principles for the tools, culture, and processes. As Larry points out, “Tools that don't give results for hours or sometimes days or lack the ability to integrate well with the dev team's other tools and practices are a non-starter. What's needed to add security to DevOps are tools that must be able to do their job within a rapid-cycle CI/CD pipeline.”

Core to DevOps is not only closer integration between Development and Operations, but empowering each of them to know, understand, and perform in all areas. It requires culture and behavior shifts that can be difficult, but worthwhile. DevSecOps integrates security into the mix so that security is more than an afterthought and roadblock to deployment. It is present from the beginning and part of the habitual thought process for everyone, throughout every step of the pipeline.

“DevSecOps is empowering engineering teams to take ownership of how their product performs in production, including security.”

Developers need to create a habit of thinking about and building for security from the beginning. Again, this requires behavior change, and, as Larry underscored, “If you are trying to change the behavior of developers, you should be a developer yourself. Bolt-on security by security specialists won’t scale. So, security must be a primary concern of the development team.”

The key is that the development team takes the primary responsibility that the product is ready to ship, but how do you get them to take ownership? Larry lays out a three-part framework for adopting new practices for a DevSecOps culture change:

Step 1 - Win the hearts and mind of the people you are trying to change. There is a cavernous lack of trust between dev teams and security teams: security is a hinderance or give us work that doesn’t matter and dev can’t be trusted to do anything.

There are three tools Larry recommends to do this:

Tool 1 - The DevSecOps Manifesto

• Build security as opposed to just bolting it on

• Rely on empowered engineering teams more than security specialists

• Implement features more securely rather than security features

• Rely on continuous learning instead of end-of-phase gates

• Build on culture change, not simply policy enforcement

Tool 2 - The Pledge. The security team needs to have dev understand these are the risks that you will expose.

We, the Security Team. . .

Recognize that Engineering Teams. . .

• Want to do the right thing

• Are closer to the business context and will make sure trade-off decisions between security and other risks are considered

• Want information and assistance so they can improve our security posture

Pledge to. . .

• Lower the cost/effort side of any investment in developer security tools or practices

• Assist 2x as much with preventative initiatives as we beg for your assistance reacting to security incidents

Understand that. . . We are no longer gate keepers but rather tool-smiths and advisors.

Tool 3 - The Trust Algorithm. This helps to understand the influence of factors on trust and how to use them to build trust. For instance, trust is eroded by more apparent self-interest. If developers view the security requests as, “Do this for us so we can do our job and look better,” it will harm the trust they have. However, if it is viewed as, “Do this so we can stop a pubic data breach that would erode our stock value - which we both gain or lose from,” it lessens the apparent self-interest, increasing trust.

     The Trust Algorithm

trust = credibility + reliability + empathy

            ----------------------------------------------

   apparent self-interest

Step 2. DevSecOps self-assessment. It takes about 90 minutes. Make it easy for them to complete the steps. Pick one or two red cells that you want to turn green in the next quarter, do what it takes to help them, and put the biggest bang for the buck on the top so they know where to start.

Step 3 - Get management involved. This is the last step that Larry outlines. He suggests to visualize DevSecOps maturity with a roll-up of the self-assessments. The height of green, amber, and red bars represent the number of teams in the organizations that are at that level and how much each level has changed over time. This is to shift their focus away from just vulnerability reports - they need to see positive changes. Make sure you let management set the goals and then see progress towards the goals.

If you want to explore the Trust Algorithm more, Larry penned a five part blog series on it for DevSecOps Days.

Larry’s full talk from the 2018 Nexus User Conference includes more detail about each step - you can watch it you can watch it here.