Shift left is one of the most popular terms within modern cybersecurity, used heavily in vendor marketing campaigns and as a headlining topic at industry conferences worldwide. As a result, the core objective and best approach to shift left has become unclear. While shift left has increased in popularity in recent years, it’s important to recognize that it is not a new concept. 

Years ago, organizations utilized the waterfall method of development, kicking off a project, scoping requirements, then designing, building, testing, and deploying software. Using this model, flaws and bugs made it all the way to the testing phase before they were identified, ticketed and sent back to development teams to fix. This method made it costly to resolve flaws. Through the gradual evolutions of DevOps and the creation of CI/CD tools, the process of fixing bugs naturally evolved to earlier in the release cycle — the founding of shifting left.

By integrating testing measures sooner in the life cycle, developers were enabled to fix issues faster as teams were immediately notified about problematic code. Code could also be pushed to production faster as teams no longer wait on manual review, and testing policies were consistent throughout. This was a huge win for productivity. 

Shift Left and Security Testing

But what does shift left mean when applied to security testing? Security testing is unique, as it usually does not take place until the code is live in production. Shifting security left is utilizing the same principles that improved efficiencies in quality testing and applying them to how teams find and fix security flaws. Shifting security left makes testing frequent, automated, and consistent. 

There are many benefits to shifting security left. This includes:

• Secure and efficient delivery of new software: Perhaps the most important reason to shift left is the efficiencies it creates in delivering secure software. By embedding security testing to release cycles, security flaws can be discovered and remediated faster. 
• Empowers developers: Enabling developers to own security testing means that they spend less time handling security bugs, allowing them to focus on more high-priority tasks — i.e., writing code. Snyk estimates that developers spend, on average, 8 hours investigating and remediating a security bug after the security team has created a ticket. Shifting security left means that this entire cycle can be short-circuited as developers can fix security bugs the same way they fix all other flaws.
• Scaling security responsibilities: The ratio of AppSec to Engineering teams is 1:100, leaving security unable to keep up with the speed as engineers are deploying new software. Shifting security left means organizations can consistently scale efforts across the company. Security leaders can set the policies and monitor the state of application security over time, while developers can review vulnerable findings and work on fixes as they push new code. This allows security teams to keep a pulse on the security of web applications and APIs and focus more on collaborating with developers on complex issues.
• Better protection of apps: Shifting security testing left also means better protection of organizational applications, APIs and microservices. 

Now that we’ve explored the benefits of shifting security left, let’s delve into how organizations can begin (and continue to sustain) such a process: 

• Invest in developer-first tooling: Security tools with a developer-first approach are built for shifting left. Choose a solution that helps developers fix security flaws in addition to surfacing them. Some features to look for include detailed fix guides, well-maintained docs, and first-class integrations with popular DevTools.
• Automate security testing *in* CI/CD: Adding automated security tests in CI/CD makes security part of the software development lifecycle instead of a disjointed process. Find a modern tool that integrates with popular CI/CD providers to start testing early and often.
• Partner with developers in their preferred environment and leverage their existing workflows: Application security has to revolve around developers and their processes to reduce the number of vulnerabilities that make it into production. Align security testing with other software tests, such as unit and integration tests, to encourage developers to ship secure code by design.

This article originally ran in Today’s Cybersecurity Leader, a monthly cybersecurity-focused eNewsletter for security end users, brought to you by Security magazine. Subscribe here.