DevSecOps and Development: Making the World Safer One Application at a Time

If you have been around software development much at all in the past 5 or 10 years, then you’ve certainly heard of DevOps and know that it is here to stay. And it is very likely that you have also heard the term “DevSecOps” in one form or another. With today’s extensive proliferation of application capabilities being delivered through services – and all the inherent complexity that comes with the delivery systems for them – it’s no wonder that CyberSecurity has moved to the forefront for many companies. In fact, according to research from Stratistics MRC, the current Global Application Security Market is growing at a CAGR of 23.4% and is expected to reach over $10 Billon by 2023¹. 

It’s one thing for there to be an interest in Cybersecurity – it’s another thing entirely to implement it well and that is where the conversation gets more interesting. Today, the name of the game in application security is all about bringing the role of the developer into the fold and equipping developers to code, fix and maintain security as part of the software development process. This notion of developer empowerment being a critical aspect to success is gaining momentum. For a great view on it, please see this excellent article from DevOps author and thought leader John Willis. Indeed, this topic was something that I heard again and again at the recent 2018 Black Hat USA Conference, and you can read more about that in this DZone article. But how do you effectively bring developers into the security fold? That is what we will explore in this two-part series.

In this first article, we will focus on what I believe is the single most important factor for long-term success – the organizational culture; the day-to-day environment of the organization the developer is a part of, and how they do their work.  A successful DevOps culture is one that promotes collaboration to foster innovation and speed delivery, and the following two sections of this article depict perhaps the two most critical components for a strong DevOps culture:  leadership and trust.

It All Rises and Falls With Leadership

Many would easily agree with the notion that long-term success for DevSecOps in an organization needs executive support and buy-in – and they would be correct – but real success needs much more than just budget approval and a shifting of resources. It needs ownership. It needs visibility. It needs truth-telling and that is where leadership comes in. According to the PuppetLabs 2018 State of DevOps Report, 64% of C-Suite respondents firmly believed that security teams are involved in technology design and deployment, but only 39% of actual team members agreed². Bridging this gap requires breaking down traditional silos and evolving for better communication and transparency.  The same survey also found that high-performing organizations were 24% more likely to use automated security policy configurations² – a clear indication of tighter cooperation between security teams and the operations teams maintaining production environments.

So, what are the key ingredients of successful leadership in this space? 

• Balance: Is the organization able to balance lowering technical debt with new work?
• Shared Ownership: Does everyone see how they contribute to business success and how their role impacts it? Is security included in that?
• Shared Learning: As projects progress and complete, is information moving across teams and projects? Are there best practices, lessons learned, etc. that are communicated both internally and externally?
  • Another way to think of this one – is the level of “tribal knowledge” in your organization getting reduced?
• Shared Vision Goals: Does everyone see and understand what matters most? Do they know the core metrics and KPI’s – and how what they do impact them? Can they see their own success and bottlenecks?

In order to have great success you need leadership that defines the key standards, actively facilitates learning and collaboration and provides the freedom necessary for innovation to occur. Another reason why you need it - great leadership builds trust. 

Your Speed of Delivery Is Directly Proportional to Your Level of Trust

The best depiction I have seen that correlates the speed of delivery with trust is this simple equation, shared with me by DevOps Technical Evangelist, Al Wagner, and written by our mutual friend and Senior IT Specialist, Lee Reid.  It states:³

Where “T” simply stands for time. In this simple equation, you can see that the HIGHER the percentage of trust is in the organization, the LOWER the overall value of the Time to Delivery will be, which is what we are all after. This tells us that businesses cannot tolerate a tradeoff between speed and quality – you need both simultaneously.

But how do you calculate trust? In this model, we are not talking so much about the work habits of the individuals as much as we are considering the outcome of each part of the process.  We have to consider how often each of these areas “gets it right” versus how much we have to go back and rework.  Lee provides this example based on a client scenario:³

“On a given project team the plan has about a 50/50 chance of being right, and the design is about 85% right, and the developers will get about 90% of the implementation right, and the testers have about 90% of the test cases right, and the release team has about 95% reliability of having the right stuff together to release, then your trust factor is something like .5 x .85 x .9 x .9 x .95 = 32% Trust”

Putting that back into the simple equation above, this level of trust means that your delivery time is 3 times longer than it could be.

When my children were doing homework, I used to tell them that sometimes the best way to go fast is to go slow. The point was if you wanted to solve problems you first had to understand them. Rushing a formula or trying combinations of numbers doesn’t work well and ends up taking you twice as long to get done. This notion of trust and DevSecOps is similar, and when you make the initial investment to build trust, it can make a real impact. While it is true that adding application security to the T_plan and T_design parts of the process will initially increase those values, having application security as part of the software delivery process from the start – instead of at the end of a release cycle – will naturally cause the values for T_Develop, T_fix, and T_Evaluate to shrink. This is largely because you do NOT have to go back to rework security into those areas midstream. It could also actually shrink T_plan and T_design over the life of the project for the same reason. In addition, the overall level of trust goes up because the risk that is associated with the delivered items decreases. We are more confident that artifacts are secure if vulnerabilities were identified early and fixed.

Closing Thoughts

Leadership and Trust. Two essential criteria for long-term success in the DevSecOps space. In Part 2 we will explore the other key areas necessary for successfully incorporating development into security.

If you would like to learn more about how you can build trust, lower risk, and make a real business impact with application security, read this case study on IGT, and then see for yourself with a trial of IBM Application Security on Cloud.