Dev.Sec.Ops.
Have you heard the term before? If not, you’re not alone. The basic premise behind DevSecOps may even go by different names, depending on who’s doing the talking (Rugged DevOps, SecDevOps, etc.) And of course it can be difficult enough even to dig up a commonly agreed upon definition of DevOps on its own—minus the sec.
So, what does DevSecOps mean, exactly? The first—probably obvious—thing you need to know is that the “sec” in DevSecOps stands for security.
For many organizations, implementing a DevOps mindset involves “bridging the gap”—or “removing silos between”—software development and IT operations teams, often with the goal of being able to release software faster, and with greater stability.
DevSecOps, then, is an extension of the DevOps mindset, and is often presented with the tagline of “shifting security left” (i.e., earlier) in the software development lifecycle (SDLC), rather than tackling security reviews/inspections at the end of the cycle, when any findings requiring mitigation are more difficult and costly to implement.
In fact, the principle behind DevSecOps—keep pushing quality closer to the source—is a key tenet of The Second Way of DevOps (feedback) as discussed in The DevOps Handbook:
“In complex systems, adding more inspection steps and approval processes actually increases the likelihood of future failures. The effectiveness of approval processes decreases as we push decision-making further away from where the work is performed. Doing so not only lowers the quality of decisions but also increases our cycle time, thus decreasing the strength of the feedback between cause and effect, and reducing our ability to learn from successes and failures.”
W. Edwards Deming, an engineer, professor of statistics, and management consultant who is often credited with the teachings that helped launch the Total Quality Movement in the United States, put forth the same idea (much earlier) in the third (of his 14) key management principles for transforming business effectiveness:
“Ease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.”
These principles aren’t new, and they seem pretty straightforward in theory, but the reality is that in practice, many organizations aren’t operating this way.
If security is prioritized by an organization, it is often aimed at achieving the minimum criteria for some sort of compliance, usually with an understaffed security team.
In his DZone article 10 Tips for Integrating Security into DevOps, Gene Kim describes this challenge:
“The ratio of engineers in Development, Operations, and Infosec in a typical technology organization is 100:10:1. When Infosec is that outnumbered, without automation and integrating information security into the daily work of Dev and Ops, Infosec can only do compliance checking, which is the opposite of security engineering—and besides, it also makes everyone hate us.”
One telling example of this scenario is illustrated in The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, where the not-so-popular, binder-carrying Chief Information Security Officer (CISO) character, John, goes through an existential crisis when his company passes a SOX-404 audit without ever needing to rely on his process-heavy security controls.
After a period of wallowing and soul-searching that all his hard work wasn’t really adding value to the company, CISO John “rises from the ashes,” humbled, and begins seeking to understand how his role can help the company achieve their business objectives, working more cooperatively with the software development and IT operations departments to understand how he can help make their jobs easier. Soon the Dev, Ops, and InfoSec triad start working together to tackle those common business objectives, and become much more agile in the process, adding automation to reduce effort and security risks wherever possible.
In an interview with Computer Business Review, Sonatype’s own CTO, Brian Fox, shared his thoughts on the shift that’s happening in the DevOps and DevSecOps space:
“What we see in the market is that our customer’s greatest challenge today is often the cultural change required to get all of the process owners to think outside the legacy process box they find themselves in.”
One of the founders of DevSecOps, Shannon Lietz of Intuit, echoes that sentiment in her What is DevSecOps? blog post on devsecops.org, stating “…with the change of DevOps afoot, traditional security is no longer an option.”
According to Lietz:
“The purpose and intent of DevSecOps is to build on the mindset that ‘everyone is responsible for security’ with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.”
When you think of DevSecOps as a collaborative discipline, the key ingredient for a successful approach often comes down to a shift in the cultural mindset of the organization as you shift left.
The authors of The DevOps Handbook agree:
“By doing this, we truly make quality everyone’s responsibility as opposed to it being the sole responsibility of a separate department. Information security is not just Information Security’s job, just as availability isn’t merely the job of operations.”At Sonatype, our approach to DevSecOps includes “building quality in” by integrating security measures into all stages of the DevOps pipeline—a shift left and right, if you will—from initial open source component selection to building, staging, and releasing your application.
When you’re integrating security into all stages of your SDLC, you’re also doing things like:
And with that, we’ll leave you with an excerpt from the DevSecOps Manifesto from devsecops.org, which is at the heart of our mission at Sonatype:
“By developing security as code, we will strive to create awesome products and services, provide insights directly to developers, and generally favor iteration over trying to always come up with the best answer before a deployment. We will operate like developers to make security and compliance available to be consumed as services. We will unlock and unblock new paths to help others see their ideas become a reality.”
This post was originally published as a Sonatype Guide, a part of our Sonatype Community. The Sonatype Community is a place where you can ask questions to other Nexus users and the Sonatype team. It also provides content and learning paths from a team of experts that help make using Nexus even easier. If you haven't spent time there, I definitely recommend it.
In the next article, Why DevSecOps?, learn more about the problems DevSecOps seeks to solve and the business case for implementing DevSecOps in your organization.
Sources:
10 Tips for Integrating Security into DevOps by Gene Kim
Five Questions with…Sonatype CTO Brian Fox by Ed Targett
The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations by Gene Kim, Jez Humble, Patrick DeBois, & John Willis
The DevSecOps Manifesto: https://www.devsecops.org/
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, & George Spafford
W. Edwards Deming Wikipedia entry
What is DevSecOps? by Shannon Lietz