The 3 Ways of DevSecOps (Part 1)

Have you read “The Phoenix Project“? If you haven’t, you should! It mirrors the method used by Goldratt in “The Goal,” first published in 1984. It’s a story, not a textbook. The Phoenix Project will help you understand the problems that arise in the way software is being built and deployed today and the ways that DevOps can help. In it, we are introduced to the Three Ways of DevOps. You can also read about them in Gene Kim’s blog post. I think they are extremely powerful and foundational concepts.

As a security professional and software development practitioner, I wanted to marry the two worlds into something that would make sense to security, resonate with developers and stay true to DevOps. The result is the Three Ways of DevSecOps. I know, I know … Why do we need to say DevSecOps? I’ll just point you at a great article by John Willis that will hopefully put that objection to rest.

I will break this out over three posts, so keep coming back and I hope that by the end I will have helped you be more successful in your AppSec program in general and in your DevSecOps programs in particular. Agree or disagree, I would love to discuss this with you on Twitter @PeteChestna. Does this resonate with you? Where did I get it wrong? Let me hear from you.

The First Way of DevSecOps: Flow

The first way, initially known as Systems Thinking, is now being called Flow in the recently released “Beyond The Phoenix Project” audio series. Think of it simply as the value stream between idea and customer and the performance of the system/people that create the value in that stream. In a company that values the security of its applications, security must be a part that value stream.

To make DevSecOps a reality, there are two things that are absolutely mandatory to getting the best results. Without these, everything is a struggle. With these, progress becomes easier. As with most problems, application security is like Soylent Green—it’s people!

You must start with the relationships between security and development teams. If they don’t know each other, why not? Are you not playing for the same team (company), after all? It’s likely that their goals are not in alignment. How would you know unless you discuss it? It’s easy to play us versus them when they are just a department or silo. “Those developers are just doing it wrong.” “Security keeps slowing us down”—these are the kinds of statements that have been said for decades. How’s that working for us? If we get on a first-name basis, cooperation becomes easier. Our enemies are on the outside. Let’s start acting like it.

The second ingredient is mutual accountability. This is the gold standard. It is the one thing that every AppSec professional needs regardless of development methodology. See my previous post about it here. If you get this done right, you are more than halfway there. Most organizations struggle with this. I was at a BSides security conference last year and one of the OWASP chapter leads stood up and stated: “We will hold the developers accountable!” He was very aggressive. It felt like one of those “go grab your pitchfork” moments. This is exactly the problem with how we treat each other. How does he expect the development teams to react to his aggressiveness? Does he care? I can’t answer those questions, but I’m sure you know what will happen: Compliance. Compliance sucks. I want more. Fortunately, my talk was after his. When I started my talk, I suggested that it would be a much better world if we could convince the developers to take accountability. They wrote it, why shouldn’t they feel accountable? Similarly at this past RSA, I was in a meeting with one of our best customers. I have known the CISO for many years and I have a great deal of respect for him. He was talking about the CI/CD pipeline and how he was going to enforce the policy on the teams. I was stunned. I stopped the conversation and suggested that it was the wrong message and the wrong goal. What if he could get the developers to embrace his security policy? Wouldn’t that be better? Let’s turn from push to pull. Would you rather change enforced upon you or would you rather be given the chance to embrace it? We all need to reboot our attitudes. Words matter here.

The way to accomplish mutual accountability is simple in concept: Leadership must be the example. The C-levels in charge of security (CISO) and development (CIO) must commit to application security as a measured individual goal to the CEO. This must include frequent, regular, transparent reporting directly to the CEO. Too many times I have seen security teams try to win hearts and minds one team at a time. They are working at the bottom of the pyramid where there are hundreds or thousands instead of the pointy end where there are only two. It’s time to rethink our tactics. Either security is important or it isn’t. If it’s not, then there are a ton of companies looking to put you to better use. If it is, then let’s put our paycheck where our mouth is. Believe me, when the CEO starts asking questions, the CISO and CIO will do most of the work for you. They will ask you for data broken down by their direct reports and so on and so on. Behavior and culture will change. It will take time. Be patient but determined!

Stay tuned for the next installment of my Three Ways of DevSecOps series, “The Second Way: Amplify Feedback Loops!”

Sponsored Content
Upcoming Webinar
Not All Flaws Are Created Equal: The Difference Between a Flaw, a Vulnerability and an Exploit

Not All Flaws Are Created Equal: The Difference Between a Flaw, a Vulnerability and an Exploit

According to Gartner, the application layer contains 90% of all vulnerabilities. However, do security experts and developers know what’s happening underneath the application layer? Organizations are aware they cannot afford to let potential system flaws or weaknesses in applications be exploited, but knowing the distinctions between these weaknesses can make ... Read More
May 29, 2018
Pete Chestna

Pete Chestna

Pete Chestna has more than 25 years of experience developing software and leading development teams, and has been granted three patents. Pete has been developing web applications since 1996, including one of the first applications to be delivered through a web interface. He led his company from Waterfall to Agile, and finally to DevOps in addition to taking the company from a monolithic architecture to one based on microservices. Since 2006, Pete has been a leader in the Application Security (AppSec) space and has consulted with some of the world’s largest companies on their AppSec programs. In addition to his role as a contributing editor at DevOps.com, he now shares his experience by speaking internationally at both security and developer conferences on the topics of AppSec, Agile and DevSecOps. Buy him a whisk(e)y and he’ll tell you all about it.

pete-chestna has 2 posts and counting.See all posts by pete-chestna