Shift left testing
Traditionally, application testing was implemented during the last phases of development, before being sent to security teams. If an application did not meet quality standards, did not function properly, or otherwise failed to meet requirements, it would be sent back into development for additional changes. This caused significant bottlenecks in the SDLC and was not conducive to DevOps methodologies, which emphasize development velocity.
Shift left testing makes it possible to identify and fix defects much earlier in the software development lifecycle. This streamlines the development cycle, dramatically improves quality, and enables faster progression to later stages for security analysis and deployment.
Shift left security
Until recent years, security testing was implemented at the end of the development cycle, following application testing. At this stage, security teams would perform various types of analysis and security testing, such as static analysis (SAST) and dynamic analysis (DAST).
The results of security testing would either permit the application to proceed for deployment into production, or reject the application and pass it back to developers for remediation. This resulted in long delays in development or increased risk of releasing software without necessary security measures.
To shift security left means to implement security measures during the entire development lifecycle, rather than at the end of the cycle. The goal of shifting security left is to design software with security best practices built in, and to detect and fix potential security issues and vulnerabilities as early in the development process as possible, making it easier, faster, and more affordable to address security issues.