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

The purpose of the “Shift Left” infographic is to provide food for thought when discussing Application Security. The aim of the slightly different “DevSecOps” version is for discussing subtleties and nuances in relation to “Continuous Hardening”.

Download a suitable version size. Pin the large A1 version to your office wall or share a smaller one with your colleagues 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, however, it adds an interesting twist to the application security message. It is based on the equivalence between “DevSecOps” and “Continuous Hardening”, which itself is the answer to the question “How to achieve the purpose of DevSecOps?”, which is about building and running secure software.

Download the “Continuous Hardening” Version

Download the “DevSecOps” Version

The overarching theme of the poster is about discussing the most important drivers which foster or inhibit the propagation of proactive security. It’s 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 practitioner 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.

The purpose is to serve as mental map in security discussions. It contains the absolute minimum one needs to understand, why we are constantly having these issues and what management and the IT guys can do to get better.

IT Security is a complex topic with the tendency of endless technical detail discussions and a lot of finger pointing. It helps to have a common language and various perspectives from management and developers in order to guide anyone with the desire to understand, discuss and improve the state of Application Security in an organization. Bridging the divide between management and people on the ground in the IT trenches is essential to improve the quality of IT Security.

“Shift Left” and “Security by Design” are important concepts to achieve this goal. “DevSecOps” is also important, however, it’s not yet a broadly accepted notion and has many critics, which is the motivation to have an alternative version with “Continuous Hardening” in order to open up the discussion.

  1. Take the version on the left in case you would like DevSecOps not to stress that much:
    “Continuous Hardening” is here an important driver. DevSecOps is mentioned here only in relation to DevOps scenarios, so that it almost disappears from the story in favor of “Continuous Hardening”. This makes the Application Security story more generic. However, it has at the same time a more limiting effect on DevSecOps, hence the notion “Narrow DevSecOps” was coined.
  2. Take the version on the right if you want to stress the importance of DevSecOps:
    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.

Now, let’s discuss different DevSecOps camps and where you might fit in.

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

Generally speaking, the earlier there are security activities in the development process, the more it is efficient and makes sense. As this happens on or towards the left side in the SDLC, the more you “Shift Left”, the better it is.

However, there is a fundamental difference between mechanically implementing items on a security requirements checklist in order to improve something and creating a holistic “Security by Design” blueprint. Improvement activities and designing activities are completely different pairs of shoes!

As example, it’s certainly possible to add airbags, ABS and modern seat belts to a classic VW beetle, convert it to an electric vehicle, making it an 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 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 (as from the film classic) but it will hardly be possible to turn it into a school bus.

You cannot easily add a large twelve cylinder engine or 40 bus seats with ordinary tuning and improvement activities. You would also need to rethink its base architecture for such changes as a VW beetle is simply lacking adequate structural support. Changing the architectural structure is a completely different effort requiring a different breed of specialists. It would not be smart do start with a VW beetle and convert it later into a school bus. Better to start with a bus blueprint in the first place and add then the looks of a beetle.

Some changes are simply not possible with an incremental approach, requiring a massive effort, probably including going back to the drawing board. The question is how far this is possible within an existing DevOps or DevSecOps organizational framework.

Does your DevSecOps only cover security patching?

The release date is an important milestone to differentiate between left and right regarding the SDLC. While there is a development project working on the release, the focus is on the left side.

The release date acts like a watershed with everything coming afterwards as being on the right hand side. This is the area of operations and maintenance. Clearly, DevOps covers both aspects. It’s also great for DevSecOps for efficiently implementing security requirements during development or for addressing security defects later after the release with security patches.

However, what to do in case of Waterfall development projects? The point is that a Waterfall development project ends with the release. What kind of process would 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.

It makes sense to maintain know-how and capacities after the release for security improvements, therefore enhancing operations with development, testing and deploy infrastructures could also be helpful in case of Waterfall like projects. However, how far you can go depends on the type of people and organization involved and what remains as infrastructure and processes in place from the previous development project. It might then be great to use the same infrastructure for Continuous Delivery as for DevOps/DevSecOps. Maybe it’s good enough for a quick security patch and maybe this is all what is needed. However, such a focus still looks like security as afterthought.

Here a strategic question to the CEO: What could happen to your business and how quickly could 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!

The focus on patching is then probably not good enough as it might require a more radical “Shift Left” approach.

What’s in a name? “DevSecOps” is actually “Continuous Hardening”!

The poster uses 3 key concepts for promoting Application Security. “Shift Left” is used to motivate the adoption of proactive Application Security because it reduces risks and might be cheaper in the long run. “Security by Design” is self-explanatory and logical as a good design does not happen by itself out of the blue. The same can be said for “Continuous Hardening” as the aim for better product quality through continuous hardening improvement activities during development or after the release is easy to understand.

However, it also makes sense to use “DevSecOps” instead of “Continuous Hardening”. The very practical reasons to go with DevSecOps is because it’s related to DevOps which has gained a strong momentum globally. Someone who is jumping on the DevOps wagon as the future of IT development and operations could hardly argue against DevSecOps. DevSecOps makes absolutely sense in a DevOps world of continuous development, continuous integration and continuous delivery.

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 in that sense like a god sent 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’s a discussion about “Who is involved?”, “Why?”, “When?” and “Where DevSecOps should happen?”, then the discussion focus is about collaboration and communication across different Dev, Ops and Security teams. However, collaboration is certainly not a new aspect for a good IT professional. 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 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 and promote this further 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’s straightforward to say that DevSecOps is about getting security quality into the end product in a continuous and sustainable way. DevSecOps can be understood as synonymous for “Continuous Hardening” because without continuous improvement activity it’s impossible to maintain this goal in the long run.

The point is that not only the underlying technology dependencies constantly change, i.e. third party libraries and frameworks, but probably also the use cases related to the IT environment. A product that was once designed and developed for isolated environments might all of the sudden become used over the Internet. Clearly, maintaining or managing the intended security level during the whole product life-cycle is required in order to stay consistent security-wise.

The 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 does not relate to DevOps scenarios to take DevSecOps like thinking into consideration?

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

Advantage and disadvantage of the “DevSecOps” buzzword

DevSecOps is a buzzword, obviously. However, it’s a useful one because of three powerful elements: 1) A mindset of continuously improving security, 2) it strongly relates to the DevOps movement and 3) it promises efficiency increases through security testing automation.

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

However, there is another 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 hype 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. Some think that DevOps or DevSecOps means that 1 person now has to cover multiple roles simultaneously
  4. Some think that DevSecOps can be ignored if DevOps is not used
  5. Some think that DevSecOps is not required because it automatically comes with DevOps
  6. Many IT people get allergic to buzzwords (rightfully) and the methodology arena is plenty of it
  7. Buzzword based discussions are often superficial and a time loss

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’s not a helpful notion.

I am a big supporter of DevSecOps as I created this poster some years ago (now on version 1.2.23). What I especially like about DevOps and DevSecOps is its potential to get IT Security to the next level by changing mindset and quality culture in the IT trenches. Better collaboration between teams across the silos and continuous quality improvement processes are very promising. Furthermore, there is also the potential to leverage testing automation for working with, creating and testing “Security as Code”. It’s 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 a problem I try to address with having two poster versions.

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’s 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 might have either a narrow, more exclusive view on DevSecOps, while others might 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’s not about arguing which version is right, because both base on the equivalence between “DevSecOps” and “Continuous Hardening”. Furthermore, DevSecOps is still not well defined. It’s therefore advisable to be pragmatic, flexible and appreciative about wording and intention context 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 more “Narrow DevSecOps” approach and you would rather discuss these security aspect in terms of “Continuous Hardening” in your non-DevOps related projects. Therefore, you would use the “Continuous Hardening” poster and skip DevSecOps terminology when it’s 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 addressing 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 they are published in three different sizes under a creative commons license for better sharing. Print out the A1 version and hang it on your wall. I hope you find this useful.

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

Author: Roberto Di Paolo

2019/4/7~4/19 ©ACROSEC Inc.
update 2021/9/1: Rearranged and typo corrections
Last update 2021/9/17: Poster update