Whether you are a seasoned security expert, or a developer looking to do more with security, you have probably come across the term “shifting security left.”
This phrase has been gaining popularity over the last couple of years. But what does it actually mean and why is it important?
Here is the breakdown 👇
Level Setting: What Does Shift Left Mean
Shifting Testing Left for Code Quality
While shifting security left has become more of a buzzword recently, the concept of shifting left is not new.
At its core, shifting left means taking things that are done toward the end of the software development workflow and moving them earlier in the process.
To help us unpack this, let’s think of software delivery through the (outdated) waterfall method of development. It used to be teams kicked off a project, scoped requirements, designed, built, tested, and then deployed software.
With this model, bugs made it all the way to the ‘testing’ phase before they could be found by a QA team. This made it costly to resolve flaws.
[source]
But through the evolutions of agile, DevOps, and the creation of CI/CD tools, the process of fixing bugs naturally evolved to earlier in the release cycle.
For everything from builds to integrations, pushing testing earlier in the cycle came with huge benefits. Developers could fix issues faster because they were notified immediately about problematic code, code could be pushed to production (aka prod) faster because teams weren’t waiting on manual review, and testing policies were consistent.
In short, developers could focus on coding, and automated testing did everything else.
A huge win for productivity 🎉
What Shift Left Means When Applied to Security Testing
What makes security testing different, is that it often doesn't happen until code is live in production.
Shifting security left means taking the same principles that modernized quality testing and applying them to how teams find security bugs.
Every time developers check in code, automated security testing runs and notifies a developer if they have introduced a new security bug.
Shifting security left makes testing frequent, automated, and consistent which comes with huge benefits for both developers and security teams.
The Most Important Reasons to Shift Security Left
Not convinced that shifting security testing left is right for your team? Or just can’t find the bandwidth to make it a priority? Let us give you some food for thought on why this should move up your priority list.
The Core Driver: Efficiency In Software Delivery
The most important reason to shift security left is that we can be more efficient in how we deliver secure software.
We have seen how transformative this can be with DevOps and embedding unit and integration testing into our release cycles. Bugs are found earlier, fixed faster, and we release better quality code.
Doing this with security testing means that developers can fix security bugs faster, security can better scale to support large development org and your apps are better protected.
Shifting Security Left Empowers Developers
It’s not a secret that a developer’s job encompasses a lot more than writing software. In fact, most developers spend less than half their day coding.
Now you may be thinking, ‘if devs are already not writing code, why would I add security testing to their workflow?’
You might be surprised to know that enabling developers to own security testing actually allows for developers to spend less time handling security bugs.
How does that work? 🤔
In its current form, security keeps developers from doing their job of product delivery. When a security bug is found (most likely in production), the development team is faced with a few unhappy realities.
First, their sprint is interrupted. That billing project you were working on? Please put that on hold. Your first priority now is to fix this cross site scripting vulnerability the security team just found. There goes the plans for the week.
No matter your role, you are probably familiar with how being assigned a new, urgent project can be draining and frustrating. This is called context switching, and for developers it is a well known killer of productivity. The developer must set aside all of the mental energy that has gone into the billing project they are working on and reacquaint themselves with code the team wrote weeks or months ago.
An important note here is that because the security testing happens in prod, there is no guarantee that the developer assigned to fix the security bug is the one who wrote the code. Testing in production inherently means sorting through large code bases written by a team of developers to trying to find a needle in a haystack.
As you can imagine, all of these forces working together equal a long mean time to resolution for security bugs. Snyk estimates that developers spend 8 hours investigating and remediating a security bug after a ticket has been created by the security team.
Shifting security left means that this entire cycle can be short circuited. Developers can fix security bugs the same way they fix all other bugs.
Security testing runs alongside build and integration testing, as software is being built and compiled by CI/CD tooling. If a new vulnerability has been introduced, developers are notified immediately. By doing so, bugs can be resolved faster because developers are in the proper context, they are only reviewing the code they just wrote to find the bug, and they can resolve it quickly.
All of the productivity gains we have seen by empowering developers with the tools to run automated testing elsewhere in the delivery cycle are now applicable to security testing.
Shifting Security Left Benefits Security Teams
While shifting security left allows developers to be more efficient, it also comes with big benefits for the security teams as well.
It’s no secret that security teams are stretched thin –There are 3.5 million open cyber security roles globally. It’s not uncommon for 1-2 security pros to be supporting hundreds of developers.
Shifting left allows security to effectively scale efforts across the company by providing consistency and efficiency in testing. Security can set the policies and scan for the same things every time code is checked in. The security team at One Medical found that this process improvement saved their security team 5 hours each week triaging and validating security findings.
By freeing time and automating testing, security is able to rethink their roles. Where once security’s role was focused on finding vulnerabilities, they can now provide strategic direction to their teams.
The VP of Enterprise Security at DataRobot, Jason Montgomery found this to be true for his team after they shifted security left. By changing how they tested, the security team could consult on triaging, and help developers dig into larger findings. Smaller issues could be remediated instantly in the development process.
While some in the security field may fear that shifting left equates to being automated out of a job, it seems that the opposite is true. Shifting testing left allows the team to focus on the parts of their jobs that are most important and drive the most value for the larger organization.
Shifting Security Left Better Protects Your Apps
In addition to making developers more efficient and allowing security to be more strategic, shifting security testing left also means better protection for your team’s apps, APIs and microservices.
The way security testing works today leaves security teams blocking releases or playing catch-up.
While blocking releases negatively impacts product delivery and core engineering metrics like velocity, waiting to test in production comes with much more risk.
The core reason? Testing for bugs in production means that the bugs are in production. And while we aren’t fans of pushing fear and doubt when it comes to security testing, it is important to callout that if your team is finding vulnerabilities in your live production site, so could bad actors.
Now that may not convince you to test earlier, but there are other challenges that come with testing in prod that make finding and fixing security bugs inefficient, including:
Coverage limitations. While your security testing tool may be able to spider the front end of your production application, it is notoriously difficult to reach back end services and APIs while testing in prod. This will only become more important as the threat of API security vulnerabilities grows.
Long test times. At StackHawk we frequently hear from customers that their security tests can run for 36 hours or more. Forrester cites that dynamic application security testing (DAST) scans can run for 5-7 days. Where else in the software development life cycle do we accept testing windows like this?
Difficult to remediate findings. As we touched on above, it is incredibly inefficient for security teams to throw findings over the wall to developers. Days can be wasted trying to find, triage, and fix the security bugs.
Long windows between tests. Because tests take so long to run and remediating findings is challenging, organizations tend to run tests quarterly or annually. This is especially true if the business is using an outside contractor to conduct penetration testing.
Together, all of this equates to coverage gaps that leave apps open to security bugs.
Applying consistent testing every time code is checked in means better, more secure software is shipped every time.
So What's Next?
Shifting left has already proven to be a best in class model for software testing. With modern tools, it is possible to bring this efficiency to security testing.
Whether you are looking for static code analysis (SCA) tools, static testing tools (SAST), or dynamic tools, there are options available that make it easy to fit security testing into the developer workflow.
At StackHawk, we are of course biased, but we think DAST is the best place to start shifting security left. Check out our DAST and SCA guides to help make a decision on what could work best for your team.
And if you are looking for more resources on implementation, read our guide on how to implement security testing tools like StackHawk in CI/CD.
