Shifting security left is the idea of managing and satisfying security requirements as early as possible in the software development life cycle. Imagine your software lifecycle outlined linearly on a page / whiteboard from left to right; with requirements and design on the very left and deployment and operation on the very right. Shifting left then implies moving the security activities in that life cycle as far to the beginning, or to the left, of the process as is possible.
This means collecting security requirements when the business requirements are collected, designing with the security constraints in mind and testing security early in the testing / development process.
The benefits of shifting security left are:
When security is shifted left there is less chance of a deployment being held up by missed security requirements. The security policy violations can be caught shortly after they are created, rather than at the end of the development cycle. This allows the developer to fix the issue while she is still in the context of the code that created it.
Shifting security left means less task based work for the security team, as developers become the first line in managing security. This allows security analysts and engineers to work on enhancing security posture by identifying weaknesses or further automating routine tasks.
Teams that focus on security early create more secure code. Additionally the time saved for the security allows them to work on tightening security in other areas.
When security is shifted left and built into the pipeline, software developers can catch security issues early and fix them before they go further down the line. This allows them to ensure a unit of work is completed before the move on to the next piece. This enables flow by preventing work from being sent back by the security team. Work keeps flowing in one direction, one piece at a time. This allows developers maximum efficiency by minimizing context switching and enhances predictability ensuring work is completed correctly the first time.
In practice, shifting security left usually involves automating some aspects of the security testing process. This typically involves integrating one or more security tools in your CI / CD system or DevOps pipeline but it also means rethinking how security is treated generally across the organization but more specifically across the development team. Teams begin to treat security as planned work instead of unplanned work, making time in sprint plans for collecting and addressing security requirements.
Shifting security left is a key tactic to use in implementing a DevSecOps strategy. The benefits quickly outweigh the upfront time investment to get the right processes and tools in place. By treating security as a first class concern in your workflows, your teams will begin to think about security all the way through the development process.