Understanding DevSecOps

Beyond “shifting left” – An exploration of DevSecOps

Jeff Williams
© Shutterstock / Creatarka

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.

Understanding DevSecOps

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. 


SEE ALSO: Common sense DevSecOps tips for developers

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.

SEE ALSO: How to adopt a DevSecOps methodology: Start by taking a look at culture

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.


Jeff Williams

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast. Previously, Jeff was co-founder and CEO of Aspect Security, a successful and innovative application security consulting company acquired by Ernst & Young. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 8 years and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many other widely adopted free and open projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.

1 Comment
Inline Feedbacks
View all comments
3 years ago

This is a great post, thanks for sharing Jeff.

Do you see a bug bounty program fitting in with a DevSecOps framework? I feel as though a lot of the values a bug bounty program brings to an organization align with your second pillar (ensuring instant security feedback).

Would be curious to hear your thoughts.