Beyond “shifting left” – An exploration of DevSecOps
In this article, Chief Technology Officer and co-founder of Contrast Jeff Williams discusses how to understand and establish DevSecOp and suggests some further reading and advice.
In many ways, traditional security practices have exactly the same problems as traditional software development. Security has been slow, manual, difficult to scale, and challenging to demonstrate value. These problems have resulted in a world in which applications average 26.7 vulnerabilities, applications are attacked continuously from around the world, and applications are the leading cause of breaches by a wide margin.
DevSecOps is simply an approach to achieving IT security based on the principles of DevOps. The basic idea is that if we interpret the ideas behind Agile and DevOps and apply them to the problem of creating security, perhaps we can achieve some of the same improvements in speed, accuracy, scale, and value.
It’s an idea worth exploring. Gartner has named DevSecOps one of their fastest-growing areas of interest and predicts that DevSecOps will be embedded into 80 percent of rapid development teams by 2021. Organization practicing DevSecOps have shown impressive results. These early adopters are 2.6x more likely to have security testing keep up with frequent application updates and show a 2x reduction in time to fix vulnerabilities.
There are many articles about DevSecOps and many vendors claiming to provide DevSecOps. Most of this is simply marketing. As Larry Maccherone says, “there are a lot of DevSecOps offerings that are just DevOps lipstick on a traditional security-as-a-gate pig.” DevSecOps is not just shoving traditional security practices and tools into DevOps or simply moving weak tools earlier in the process. Concepts like “shift left” and “security as code” are poorly defined and can be more misleading that informative.
To start to understand DevSecOps, we can start with the foundational principles from these books. The following “Three Ways of Security” are an interpretation of the “Three Ways” of DevOps from The Phoenix Project.
The first way of security: Establish security work flow
Traditionally, security has been performed as a series of massive unachievable tasks that attempt to span all risks. For example, writing a comprehensive set of security requirements, designing a comprehensive security architecture, performing a comprehensive security test, etc…
The first way instructs us to break this work down into small pieces, so that we can improve security over time rather than attempting to achieve everything at once. By making security work visible to everyone, it can be prioritized, measured, and completed as part of the normal development process.
The basic cycle of DevSecOps is to identify the most critical security challenge, implement a defense strategy, automate security testing for that defense, and then monitor and defend against attacks. Both our security pipeline and the security of our software gets stronger and stronger over time.
The second way of security: Ensure instant security feedback
Security is one of the most common causes of technical debt, and the cost of this work increases dramatically the farther it progresses across the SLC. How do we keep security work on track?
To avoid this common trap, organizations should automate security as much as possible, and provide instant feedback to the team members that need it through the tools that they are already using. Security feedback must be designed for consumption by developers, testers, and executives that do not have extensive security expertise. Experts do not scale.
A DevSecOps pipeline is the set of tools and processes that continuously performs security work as code is written, integrated, tested, deployed, and operated. This is really just a security-oriented view of the DevOps pipeline, but it’s useful to view this security layer separately. The feedback loop below shows instant feedback of both vulnerabilities and attacks to the teams that need them through the tools they are already using.
The third way of security: Build a security culture
Many organizations have a security culture of blind trust, blame, and hiding that prevents developers and operations from working with security. How do we create a culture of security?
The key to DevSecOps culture is to ensure that responsibility for security falls squarely on development teams. If security teams have responsibility for security, nobody else will do their part. Security experts should transform themselves into coaches and toolsmiths, and focus on teaching and automating as much as possible.
Today, many organizations struggle with a security culture centered on blame, hiding, and uninformed strategy. In DevSecOps, organizations strive to practice “security in sunshine” and celebrate both vulnerabilities and attacks as a sign of good security process and an opportunity to improve.
Choosing DevSecOps technologies
While automation is just one part of a successful DevSecOps program, it’s important to remember that security tools can be a powerful agent of change. When choosing technologies for DevSecOps, look for tools with the following characteristics, and beware of vendors selling the same old tools with new marketing.
- Policy coverage – First and foremost, you must confirm that the tool actually covers the risks you need it to cover. Many products have surprising shortcomings in this area. See the OWASP Benchmark Project for help.
- Accuracy – Accuracy (eliminating both false positives and false negatives) is critical. Inaccuracy means humans have to fix results which will destroy your pipeline. You should carefully test your tools to be sure they accurately verify what you need.
- Ease of use – Tools must be useable by developers, testers, and other team members that do not have any security experience.
- Speed – You need to test whether tools are fast enough to work as a part of your DevSecOps pipeline. That may be microseconds, seconds, or minutes but probably not hours and certainly not days.
- Scale – Consider the size of your application portfolio and whether the tools you select are capable of operating continuously, in parallel, across that entire portfolio. Be sure to factor in the number of people (particularly experts) you will need to make that work.
- Integrations – Look for well-documented, supported REST APIs and SDKs in a variety of languages, IDE plugins, webhook support, ChatOps integrations like HipChat and Slack, CI/CD integrations, notifications with PagerDuty and VictorOps, and SIEM integrations like Splunk.
The future of DevSecOps
We are still in the early days of DevSecOps. Please share your thoughts below on how we can help it succeed where other approaches have struggled.