The Elephant in AppSec Talks Highlight: Shifting Left Doesn't Mean Anything Anymore

"A bunch of marketing teams for various vendors, got a hold of this [idea of shift left] and they changed its meaning to: if you buy my product, you've shifted left and security is done" - Tanya Janca, Founder of WeHackPurple, and Head of Education and Community at Semgrep

What happened to this revered idea of shifting left? What was once the principle of implementing security earlier in the SLDC has now become, as Tanya Janca explores, a mere marketing tactic to sell products. From her talk in Track 1 of this month's The Elephant In AppSec Conference, Tanya dives into what happened to shift left, what does it actually mean, and how can you actually adopt and optimize this idea in your company?

If you're looking for the answers to these questions, this blog article will take you through the key highlights from her talk, which you can watch in full here.

What shifting left is not

The concept of "shift left" emerged from the need to involve security teams at the beginning of the development process. Traditionally, security was an afterthought, often leading to last-minute panic before a product's release. By shifting security considerations to the left of the SDLC timeline, organizations can proactively manage risks and reduce vulnerabilities.

However, Tanya highlights how marketing incentives can be "perverse" to security ones, with the goal of grabbing attention and using "fear, uncertainty, and doubt" to convince you that all buying a certain product equates to shifting left.

This is just one of the ways Tanya highlights the idea of shifting left has been warped. Here are two other things shifting left is not:

Making devs do all the work: Shift left is definitely not the idea that developers can handle everything themselves. By shifting left you don't eliminate the need to provide developers with training, support, guidance, or oversight.

Only doing security in pipelines: Security cannot just be restricted to the Continuous Integration (CI) part of the pipeline. While tools that help you threat model are very useful and can help you start security even earlier, they cannot be all that you use so security only stays in the pipeline.

Security must be a constant consideration

These oversimplifications undermine the comprehensive nature of true security integration, which involves continuous engagement throughout the development process.

Authentic "shift left" practices involve embedding security from the project's inception and maintaining it through to decommissioning.

"Reducing organizational risk is our number one priority [as security teams], everything else is bonus. Everything else is gravy." - Tanya Janca

This means security professionals should be present at project kickoff meetings, ensuring that security requirements are made clear from the very beginning, and integrated into every phase of development. You don't want to just fix bugs; you want to prevent them in the first place.

Tanya discusses how she sees a big hole in operational security for software and it needs to included even after the release. But how do you do this?

You have to work with developers

It does not matter if you buy the world's most perfect tool, if you have no processes to support it, if you don't show anyone how to use it, and you don't deploy it properly. - Tanya Janca

Tools have to work with developers and their processes. So, these security tools must integrate with developers' own tools. If they make developers' lives harder, they just won't be used and that is a lose-lose for everyone. This also means security, wherever possible, must do more than just deploy the tools. You have to support developers, teach them how to effectively use the tools, and help socialize them to create a culture of security within the enterprise.

Therefore, you have to deploy tools that developers approve, and Tanya recognizes that this does create more work up-front, but she emphasizes that it will result in much less work in the long run because these tools will then be effectively used and implemented by development teams, spreading your security throughout the SLDC just as you need.

Select program goals and measure against them

You need to have quantifiable goals. Tanya underlines the need to select a framework or create your own; you can equally choose the parts of a framework like OWASP that you like and that mold to your organization. The key here is to select goals for your program, and these goals should be measurable so that you can track progress and ensure that security efforts are impactful.

Therefore, to effectively reduce organizational risk, security programs must be data-driven and goal-oriented. This can equally contribute to the culture of security and awareness and shared responsibility when the company is united under achieving these shared goals.

Beyond Shift Left: A Holistic Approach

While shifting left is crucial, it is not sufficient on its own. Security must be pervasive, extending beyond the development phase to include operational security and maintenance. This comprehensive approach ensures that applications remain secure throughout their lifecycle, not just at launch.

Conclusion

Although the concept of shift left may be getting lost in all the noise, Tanya's talk shows us how we can still draw valuable lessons about the importance of involving and implementing security right from the very beginning of every project. Crucially, security practices then have to be maintained throughout the entire SDLC, from conception to decommissioning.

This requires a cultural shift within organizations, moving away from viewing security as a checkbox to seeing it as an integral part of the development process. By fostering collaboration with developers and setting measurable goals, organizations can achieve a more secure and resilient software environment, filling this hole we see in operational security.

Want to find out more on how to do this in detail?

💡 Want to discover more?

• Discover the Elephant in AppSec Podcast on YouTube, Spotify, and Apple Podcasts
• The Elephant in AppSec Talks Highlight: Reinventing API Security
• The Elephant in AppSec Panel Highlight: Why scaling AppSec is harder than you think
• Fortune 1000 at risk: how we discovered 100k API vulnerabilities in the world's largest organizations