DevSecOps

This partner blogpost was provided to us by our partner Sonatype.

Dev.Sec.Ops.

Dev.Sec.Ops.Have you heard the term before? If not, you are not alone. The basic premise behind DevSecOps can even run under different names, depending on who is conducting the conversation (Rugged DevOps, SecDevOps, etc.) And of course it can be difficult enough to find a commonly agreed definition of DevOps for yourself.

So, what does DevSecOps mean exactly? The first thing you probably need to know is that the “Sec” in DevSecOps stands for Security.

For many organizations, implementing a DevOps mentality means closing the gap or eliminating silos between software development and IT teams, often with the goal of publishing software faster and more stable.

DevSecOps is therefore an extension of the DevOps mentality and is often portrayed with the slogan “shifting security to the left” (i.e. earlier) in the Software Development Lifecycle (SDLC), rather than tackling security audits/inspections at the end of the cycle when all the findings that require mitigation are more difficult and costly to implement.

In fact, the principle of DevSecOps - bringing quality ever closer to the source - is an important principle of The Second Way of DevOps (Feedback), as described in DevOps manual:

“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, statistics professor, and business consultant who is often credited with the lessons that contributed to the establishment of the Total Quality Movement in the United States, brought forth the same idea (much earlier) in the third (of its 14) key management principles for transforming business effectiveness:

“Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.”

Principles are not necessarily synonymous with practice.

These principles are not new, and they seem fairly simple in theory, but the reality is that in practice many companies do not work that way.

When security is prioritized by a company, it often aims to meet the minimum criteria for some kind 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.”

An illustrative example of this scenario is The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win in which the less popular Chief Information Security Officer (CISO) John is going through an existential crisis when his company passes a SOX-404 audit without ever having to rely on his process-intensive security controls.

After a period of self-pity and self-analysis, in which all his hard work did not really add value to the company, CISO John “rises from the ashes” and begins to understand how his role can help the company achieve its business goals and works more cooperatively with the software development and IT departments to understand how he can help facilitate their work. Soon the Dev, Ops and Security Triad will begin working together to achieve these common business goals, becoming much more agile by adding automation processes to reduce effort and security risks.

A cultural change in both directions

In an interview with the Computer Business Review Sonatype’s CTO, Brian Fox, shared his thoughts about the changes in the DevOps and DevSecOps area:

“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, recalls this mood in her blog post What is DevSecOps? on devsecops.org and explains: “…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.”

If you see DevSecOps as a collaborative discipline, the key to a successful approach often comes back to a change in the company’s cultural mindset.

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.”

For Sonatype, the DevSecOps approach involves building quality in by integrating security measures into all phases of the DevOps pipeline - a left and right shift - from the initial open source component selection through to application creation, deployment and release.

In order to integrate security into all phases of an SDLC, the following points must be observed:

  • Scan and assess the risks of open source components in new and existing legacy applications.
  • Prevent “bad” OSS components from entering an ecosystem.
  • Continuously monitor all applications in production, automatically notify development teams of vulnerabilities that affect an application.

The following is an excerpt from devsecops.org’s DevSecOps manifesto, which is at the heart of Sonatype’s mission:

“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.”

For more information:

👉🏻
To the original blogpost
If you want to know what else is happening at Scandio:
Scandiolife on Instagram.
Connect with us on LinkedIn.
Look what Scandio is tweeting.