The purpose of the “Shift Left” infographic is to provide food for thought when discussing Application Security. The aim of having slightly different “Continuous Hardening” and “DevSecOps” versions is for discussing subtleties and nuances in relation to different perspectives of various stakeholders.
Download your favorite version in suitable 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).
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 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 security issues and what management and the IT guys can do to improve.
IT Security is a complex topic with the tendency of endless technical detail discussions and a lot of finger pointing. A common language and covering various perspectives from management and developers is useful 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 the 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 is 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.
- Take the version on the left in case you would like DevSecOps not to stress that much:
“Continuous Hardening” is an important driver here. DevSecOps is mentioned 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. - Take the version on the right if you want to stress the importance of DevSecOps:
DevSecOps is seen here as an important driver. A DevSecOps mindset with focus on collaboration and with its hardening tools is also very useful in other development scenarios, even in the most classical Waterfall approach, hence the term “Open DevSecOps” is used to show the difference.
Now, let’s discuss the different 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 tank or a school bus.
You cannot easily add a tank engine (as large as the size of beetle) or add 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 tank or 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 after some important design decisions have been made. Sure, it’s possible to apply an incremental approach also to the design process. Fail fast and often is a great recipe to learn a lot during this stage. However, once you got straightened up your design, you have to live with the consequence and build on top of it.
Changing the underlying structure requires a large effort, probably including going back to the drawing board in many places – which means working on the next major version. The question is how far is this possible within an existing DevOps or DevSecOps organizational framework. Is it about upgrading to version 2.0 or is it rather incrementally improving on top of what already exists in order to get from version 1.4.36 to 1.4.37?
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 goal of the development project defines what should be done, if it’s going to be a major or a minor release.
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 with minor updates. 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.
Nevertheless, what to do in case of other development methods? What about Waterfall 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 development 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 sometimes makes sense to favor “DevSecOps” terminology over “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 be 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 of higher costs and longer delivery dates. DevOps is in that sense like a god sent piece of semantic luck, because DevSecOps is the logical next step for explicitly adding Security to DevOps.
Especially as DevSecOps stands for the right things and mindset; proactive security baked-in to 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 “Hows” 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 terminology 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 a DevSecOps mindset into consideration?
The answer is that you probably can’t. It’s especially confusing for the security team if a variety of development methods are used within the organization. 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 Integration” 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 a 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:
- DevSecOps seems to indicate that it is limited to DevOps scenarios only
- DevOps is widely popular, however, still rare in some other areas or regions in the world (e.g. in Japan or many other countries)
- Some think that DevOps or DevSecOps means that 1 person now has to cover multiple roles simultaneously
- Some think that DevSecOps can be ignored if DevOps is not used
- Some think that DevSecOps is not required because it automatically comes with DevOps
- Many IT people get allergic to buzzwords (rightfully) and the methodology arena is plenty of it
- 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 the 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”. This is a paradigm shift as automatic security testing requires to have security quality baked-in right at the beginning of the development process, which is nothing less than the promise of switching to a proactive IT Security approach. 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 by 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 infographic 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 under a creative commons license in three different sizes for better sharing. Print out the A1 version and hang it on the wall in your office! I hope you find it 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
Update 2021/9/17: Poster update
Update 2021/12/10-13: Title changed, clarifications added.