⬅️ Shift Left
When we’re talking about shift left, we’re talking about shifting left security in the software development lifecycle. Instead of focusing testing efforts towards the end of development, “shift left” proposes that security is integrated into the earlier stages.
Let’s explore some arguments for shifting left!
Deleting or re-writing flawed code
By not keeping security in mind during development, you run the risk of building on top of fundamentally flawed code. As a result, you might need to re-write or even delete chunks of your codebase. Early security evaluations will reduce the chances of a fundamental flaw going unnoticed for too long.
Catching bugs early is cheap
IBM performed a study a while ago looking into the relative costs of fixing bugs in the various stages of software development. Unsurprisingly, they found that the further you get in the development process, the more expensive it gets to fix bugs.
Releasing on time is nice
Only starting to think about security near the deadline for a project introduces some serious business risk. Security auditors can find significant flaws that require some time to mitigate. As a result, launch dates might need to be moved, which can have severe strategic consequences.
You’re probably familiar with the term DevOps, which has taken software development by storm. DevSecOps builds on top of DevOps and makes the inclusion of security explicit.
Check out “The DevOps Handbook” for an excellent introduction to DevOps concepts.
In short, DevOps is a methodology that’s closely related and based on Lean and Agile. In DevOps, concepts and techniques from manufacturing are applied to software development, which turns out to be very productive.
The “The DevOps Handbook” talks about the importance of having (tight) feedback loops. The effect? Turn around times improve, teams learn efficiently, and information doesn’t get lost.
This is why Dev and Ops are connected. Instead of “throwing work over the fence” for the other team to look at, teams are unified. Operations are included in the development process for early and direct feedback on architecture and approach. Additionally, deployments are automated and integrated from the beginning (CI/ CD) instead of at the end.
Dev & Sec & Ops 🤝
Some will argue that security is already part of DevOps, and they are right. DevSecOps formalises this inclusion and allows us to refer to the tools, practices and approaches for security in DevOps.
With DevOps, operations was pulled into the software development team. DevSecOps means the same happens for security.
- Security concerns and best practices will be part of design discussions, as well as final code reviews.
- We can extend CI and CD automating as many (high confidence) security checks as possible.
Both these changes, and more, will create tight feedback loops, making sure that security is built-in, rather than patched on!
So, how do DevSecOps and Shift Left relate to one another?
Shift left is about the benefit of starting to think about security at an earlier stage of the development. In DevSecOps, security is part of every iteration and feedback loops are tight. So, with DevSecOps, you’ll shift-left security.
There is no doubt that you should shift-left, and DevSecOps provides an effective set of practices to do so. Make sure to automate as much as possible, and think about security early and often!
I hope you found this article on shift left and DevSecOps useful, let me hear your thoughts on Twitter (@JoranHonig)!
This article was originally published here: https://joranhonig.nl/shift-left-and-devsecops-what-does-it-even-mean/