Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

12/12/2018
10:30 AM
Jerry Gamblin
Jerry Gamblin
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

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

Once DevOps teams decide to shift left, they can finally look forward instead of backward.

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:

Jerry Gamblin's interest in security ignited in 1989 when he hacked Oregon Trail on his 3rd grade class Apple IIe. As a security evangelist, researcher and analyst, he has been featured on numerous blogs, podcasts and has spoken at security conferences around the world. When ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
AI Is Everywhere, but Don't Ignore the Basics
Howie Xu, Vice President of AI and Machine Learning at Zscaler,  9/10/2019
Fed Kaspersky Ban Made Permanent by New Rules
Dark Reading Staff 9/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-14540
PUBLISHED: 2019-09-15
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariConfig.
CVE-2019-16332
PUBLISHED: 2019-09-15
In the api-bearer-auth plugin before 20190907 for WordPress, the server parameter is not correctly filtered in the swagger-config.yaml.php file, and it is possible to inject JavaScript code, aka XSS.
CVE-2019-16333
PUBLISHED: 2019-09-15
GetSimple CMS v3.3.15 has Persistent Cross-Site Scripting (XSS) in admin/theme-edit.php.
CVE-2019-16334
PUBLISHED: 2019-09-15
In Bludit v3.9.2, there is a persistent XSS vulnerability in the Categories -> Add New Category -> Name field. NOTE: this may overlap CVE-2017-16636.
CVE-2019-16335
PUBLISHED: 2019-09-15
A Polymorphic Typing issue was discovered in FasterXML jackson-databind before 2.9.10. It is related to com.zaxxer.hikari.HikariDataSource. This is a different vulnerability than CVE-2019-14540.