Forget Shifting Security Left; It's Time to Race Left

It's almost the end of the year, a time when many DevOps teams take some downtime and start planning improvements for the new year. With application breaches and never-ending development framework vulnerabilities dominating headlines recently, they're looking for ways to stay out of the news.

Many teams hope they can improve their overall security posture just by introducing new security tools earlier in the development cycle. The truth is that organizations can't make these reforms with new technology alone, so we don't need to shift left — we need to race left!

Racing left isn't simply a metaphor for speed alone, but a comment on all of the preparation that goes into racing. It's a term inspired by Williams College professor Duane Bailey, who said racing is "the constant search for the weakest link." Racing left in the DevSecOps means building new processes while understanding the need for constant development, deployment, and testing.

A Race with No Finish Line
The idea that security should be deeply entrenched with the DevOps teams seems like common sense, but it doesn't usually happen. A generation of applications has been built using practices that fall far short of most common security standards, often using tools that are themselves outdated or vulnerable.

Many teams simply are not given the time, because they are in a never-ending sprint (see what I did there?) of adding new features and bug fixes for existing code. This growing development backlog keeps teams busy, but that is not the only barrier to success. There are other arguments against reforming these practices with security in mind, most of them come down to a trade-off between agility and security.

Thinking Speed Equals Winning
Time to market is a serious concern for any company developing apps. There may be competitors working on similar products, or venture capitalists eyeing the burn rate nervously. There is an immense pressure to get the latest build shipped. Inevitably, that means less time spent in quality assurance testing.

If You Are Reactive, You Are Losing
Security teams have worked as responsive teams since their invention, handling issues as they come up. Racing left requires rearranging cycles and redesigning workflows for a big chunk of the team. If you are responding to issues more than preventing them you are behind the curve.

No More Hero Mode
While management and metrics go hand-in-hand, if your security team is catching vulnerabilities in the development process before they are pushed to production, it may have a clear benefit to the app, but your team may go unnoticed in the boardroom because it will not cause the usual ripples of visibility that a found vulnerability will.

Getting Faster Is Expensive
Companies are buried in technical debt, with no realistic way out.

If the security team suddenly finds itself embedded in the development team, who is left to handle the overload of past promises? Organizations that have shifted left have had to choose between pulling support from reactive security and hiring new teams.

These roadblocks are huge (have you tried to hire an application security pro lately?), but there are huge reasons to shift left.

Let's Think of This as a "Rebuilding Season"
Racing left requires organizations to draw a red line between the past and the future. It offers a clean break from the past and frees teams from the burden of dealing with accumulated technical debt. It's an admission that the team is never going to be able to catch up. Once the decision is made to shift left, teams can finally look forward instead of backward.

Spend Minutes Now and Save Hours Later
At many development shops, the code might get all the way through development and beta testing before the first static application security testing or dynamic application security testing tools are run against it, causing the code to go back to the development team if an issue is found, or in the worst case pushed to production with a known issue. Redoing the work and retesting code takes the time that could be devoted to other things. Shifting left clearly creates more work early in the process. The long-term time savings might be hard to quantify, given the lack of clear metrics, but it stands to reason that it exists.

Racing Left Results in a Better Product
If you build apps to a documented security standard, your product is less likely to be the entry point for a devastating hack. Just look at the Equifax breach, where the vulnerability that was exploited was built atop an out-of-date framework.

Placing security teams within the workflow of continuous deployment models is long overdue. The shift left started decades ago and has proven to be a tremendous success. Though there will be internal resistance to changing the way apps are made, the long-term benefits are clear.

Related Content: