“Narrow DevSecOps” vs. “Open DevSecOps”: Which camp are you in?

You find here the most recent update of the Shift Left/Application Security poster. It comes now in two flavors (see below picture) in order to include different views on DevSecOps.

The purpose of having two slightly different Application Security poster is to provide food for thought when discussing and propagating Application Security because there are many different angles to look at it.

  1. Take the version on the left in case you don’t like DevSecOps:
    “Continuous Hardening” is seen here as important driver for realizing Application Security. DevSecOps is only mentioned in relation to DevOps scenarios, so that it almost disappears from the story in favor of “Continuous Hardening”. This makes the Application Security story generic and more acceptable. This has a limiting effect on DevSecOps, hence the notion “Narrow DevSecOps” was coined to show this effect.
  2. Take the version on the right if you think that DevSecOps is important:
    “DevSecOps” is seen here as driver for realizing Application Security. A DevSecOps like mindset, collaboration and hardening is also very useful in other development scenarios, even in the most classical Waterfall approach, hence the term “Open DevSecOps” to show the difference.

Dowload the pdf version which you find suitable and use it as poster or email it to others who might find it interesting (creative commons byncnd 4.0 license).

Shift-Left, Security by Design and DevSecOps OR Continuous Hardening
The difference between both versions is only slight as shown above. It is based on the equivalence between “DevSecOps” and “Continuous Hardening”, which itself is the answer to the question “and how can we achieve the final purpose of DevSecOps”, which is to build and run secure software.

“Continuous Hardening” Download

“DevSecOps” Version Download

The overarching theme of the poster is about identifying the most important elements which foster or inhibit the propagation of proactive security. It is not about specific security technologies but about what makes people and organizations tick when it comes to implementing Application Security.

It does not contain anything new what an experienced IT practicioner wouldn’t already know. It just depicts on one page the realities and circumstances of what security and technology practitioners experience on a daily basis in the IT trenches.

Its value is to serve as mental map because it is about a complex topic. It contains the absolute minimum one should understand in this area on the highest level. It provides a common language and several perspectives in order to guide anyone with the desire to understand and discuss the state of Application Security in organizations.

DevSecOps seems to be important to achieve this goal, however, it is not yet a broadly accepted notion and has many critics, which is the motivation to have an alternative version in order to open up the discussion for other opinions on this topic.

How far “Left” in the SDLC would you go with DevSecOps?

DevSecOps is about seamlessly baking-in security in the development process. This encompasses also security requirements for continuously improving the security quality of the end product. Generally speaking, the earlier there are security activities in the devlopment process, the better it is. As this happens on the left side in the SDLC, the more you “Shift Left”, the better it is.

However, there is a fundamental difference between mechanically following a security requirements checklist and creating a holistic “Security by Design” blueprint. Continuous improvement activities and designing security architectures are completely different pair of shoes.

As example, it is certainly possible to add airbags, ABS and modern seatbelts to a classic VW beetle, convert it to an electric vehicle, making it a open car with roll-over bars or adding all sorts of thinkable and crazy IoT gadgets, maybe even autonomous driving.

Such tuning and upgrading might be done by gifted technical folks and specialists, but the point I would like to make is that such activities usually happen within the current limits of its base architectural design. Therefore, a VW beetle might become a cute convertible, a drag race beetle or even a Herbie love bug (from the film classic) but it will hardly be possible to turn it into a Rolls Royce or into a school bus.

You cannot easily add a Rolls Royce twelve cylinder engine or 20 bus seats with simple tuning and improvement activities. You would also need to rethink its base architecture for such goals as a VW beetle is simply lacking adequate structural support. However, changing the architectural structure is a completely different effort requiring a different bread of specialists, which most probably means to redesign a completely new product from scratch. It would not be smart do start with a VW beetle and convert it later into a school bus instead of starting with a bus design in the first place.

Here a question to the DevOps people in the IT trenches: Would it be possible to completely redesign or refactor your product within your DevOps and DevSecOps organizational frameworks?

How far “Right” in the SDLC would you go with DevSecOps?

The release date is an important milestone to differentiate between left and right regarding the SDLC. It is like a watershed with everything coming afterwards being on the right hand side. This is the area of operations and maintenance. Continuous improvement activities are a good idea in order to quickly and efficiently address security defects. Even if you happen to use the most classic Waterfall development process.

The point is that a Waterfall development project ends with the release. So, what kind of process would be efficient to care about continuous improvement needs after the end of the development project? You might need to address security issues and deliver updates and patches for many years to come.

Here a strategic question to the CEO: What happens to your business and how quickly can you adapt if product liability for software security vulnerabilities becomes enshrined in law? Such legislation would most probably be a game changer for many IT and IoT related businesses!

What’s in a name? That which we call “DevSecOps” is actually “Continuous Hardening”!

The poster starts by identifying the 3 most important notions for promoting Application Security. If you need to limit yourself to 3 great notions, which would you choose?

Jargon is inevitable, however, jargon comes also in layers. It is important that on the top layer of our jargon are terms and buzzwords which are easy to understand and to communicate. Besides the point that it must make sense concept-wise, it must also be jargon that resonates well in the IT trenches and also on top management level because it’s them who decide on project budgets and time frame (aka the sponsor).

“Shift Left” is a key concept to motivate for proactive Application Security. “Security by Design” is self-explanatory and logical. It is important because a good design does not happen by itself out of the blue. It is only the notion of “DevSecOps” which just looks a bit odd here.

However, there are good reasons to use DevSecOps. It is related to DevOps which has gained quite momentum globally. Someone who is jumping on the DevOps wagon as the future of IT development could hardly argue against DevSecOps. This can become useful, because let’s face it, IT Security has never been popular in large parts of the developing community and also not in management because it costs more and takes longer to deliver. DevSecOps is like a godsend piece of semantic luck, so why not use it for promoting Application Security?

Especially as DevSecOps stands for the right things and mindset; proactive security baked-in the development process and the end-product, done in an efficient and right way for the organization and its people involved. There are many aspects to be discussed about DevSecOps.

If it is a discussion about who is involved, why, when and where DevSecOps would happen, then the focus is on collaboration and communication across different Dev, Ops and Security teams. However, is collaboration new from the perspective of IT professionals? Effective security people usually try to get close to and have a collaborative relationships with Dev, Ops, engineering and business departments in order to get the right things done. The same for good engineers and developers when they seek security advice. This simply is common sense and with DevSecOps, there is a chance to institutionalize this on a large scale within many organizations.

If you just look at the goals and the purpose of DevSecOps, then the discussion is about the “What” and the “How” of DevSecOps. It is straightforward to say from this angle that DevSecOps is about getting security qualities into the end product in a continuous and sustainable way. Under this condition, DevSecOps can be understood as synonymous for “Continuous Hardening”, because without this activity it is not possible to achieve its purpose.

This semantic trick of equating DevSecOps with “Continuous Hardening” makes it possible to open up the discussion also to those who do not like DevSecOps for whatever reason.

“Shift Left”, “Security by Design” and “DevSecOps” are great stories for promoting Application Security. However, there are inconsistencies regarding DevSecOps. How would you convince the Waterfall guys or any other person who is not related to a DevOps scenario to take DevSecOps thinking into consideration?

The answer is that you probably can’t and that it might be better to use a different jargon like “Continuous Hardening” which stands for the same goals. The use of “Continuous Hardening” is furthermore compatible with the “continuous” intention of DevOps. It allows to discuss the same outcome as would be discussed by the other crowd which rather prefers to stick with “DevSecOps”.

Advantage and disadvantage of the “DevSecOps” buzzword

DevSecOps is a buzzword, obviously, but it is a useful one because of three powerful concepts: 1) The mindset of continuously improving security, 2) its footing in the strong DevOps movement and 3) its promise of increased efficiency through test automation.

Its footing in the DevOps movement is an invaluable advantage for promoting Application Security: If you are using DevOps, and many do, then it is very difficult to argue against DevSecOps.

However, there is also an issue. The problem with DevSecOps is … DevSecOps. It’s a terrible name to begin with – even for many who spearhead what it stands for, including myself. It lacks a good definition and furthermore suffers from the current hype happening in the arena of agile development which is full of misunderstandings and buzzwords.

Here is why I think that there is an issue:

  1. DevSecOps seems to indicate that it is limited to DevOps scenarios only
  2. DevOps is widely popular, however, still rare in some other areas or regions in the world (e.g. in Japan or many other countries)
  3. Many think that DevSecOps can be safely ignored if DevOps is not used
  4. Many IT people get allergic to buzzwords (rightfully) and the development arena is full of it
  5. Buzzword based discussions are often not rewarding

The issue with the notion DevSecOps is that it can hamper the Application Security discussion when it is used in the wrong context with the wrong crowd in the wrong region. People are people and if the security discussion is not happening because of above reasons, then it is not a helpful notion.

I am a big supporter of DevSecOps, obviously, as I created this poster some years ago (now on version 1.2.21). What I especially like about DevSecOps is its potential to get IT Security to the next level by changing mindset and culture in the IT trenches but also through test automation and continuous quality improvement processes. It is the promise of a paradigm shift to have security quality baked-in in software products , which is, about proactive IT Security. This is quite significant because the majority in the IT industry is still deeply entrenched in a reactive mode.

It would be too sad if the DevSecOps promise would not even be discussed because of different understandings about development scenarios and semantics, which is the problem I try to address in this post.

The poster depicts in the lower half the two most extreme development scenarios (Waterfall vs. Agile/DevOps). They represent the extreme boundaries which is thinkable within all development methodologies. Many projects use a pragmatic combination of multiple methodologies, what is thought to be appropriate regarding project goals and organizational circumstances.

The security discussion on this poster applies also to any other development methods or hybrid combinations which are located between these two extreme cases.

Another point to be made here is that security and risk departments need to be aware of the fact that they must be in sync with the fast delivery speed of an agile/DevOps combination. It is not good for your projects and even not for your business if your security or risk departments have no idea which development methods they are facing in development projects which they are supposed to oversee or to consult.

“Narrow DevSecOps” vs. “Open DevSecOps”

Getting back to DevSecOps and the two posters: The proposal is to be aware that people have either a narrow, more exclusive view on DevSecOps, while others have a more broader, more open view on it which makes DevSecOps more inclusive to be used also in other development scenarios. Releasing two flavors of the same poster addresses this difference.

Both versions are correct and make sense. It is not about judging which version is right, because both base on the equivalence between “DevSecOps” and “Continuous Hardening”. Furthermore, DevSecOps is still not well defined. It is therefore advisable to be very pragmatic, flexible and appreciative about wording and intentions within a concrete security discussion.

This also requires to be very clear about where one stands in such a discussion and that’s why two slightly different posters might be helpful.

If you are rather critical to DevSecOps and believe that it should be exclusively limited to DevOps scenarios only, then you would prefer a “Narrow DevSecOps” approach and you would rather discuss these security aspect in terms of “Continuous Hardening” in your non-DevOps projects. Therefore, you would use the “Continuous Hardening” poster and skip DevSecOps terminology when it is not related to DevOps.

If you think that DevSecOps is great and has merits to be used even in the most strict traditional Waterfall type projects (e.g. for solving update and patching issues after the release), then you are candidate for using the “Open DevSecOps” poster version in order to propagate DevSecOps practices also in non-DevOps projects.

The goal of this poster is to promote Application Security and therefore provide food for thought for discussing proactive security practices and scenarios. That’s also the reason why thy are published in three different sizes under a creative commons license for better sharing. I hope you find this useful.

I highly appreciate any feedback if you have suggestions on how to improve the message of the posters or if you find mistakes or typos.

Author: Roberto Di Paolo

2019/04/07 © ACROSEC Inc./last update 2019/04/19