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
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Edge-DRsplash-10-edge-articles
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
News
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-27132
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
CVE-2021-25284
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.
CVE-2021-3144
PUBLISHED: 2021-02-27
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
CVE-2021-3148
PUBLISHED: 2021-02-27
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
CVE-2021-3151
PUBLISHED: 2021-02-27
i-doit before 1.16.0 is affected by Stored Cross-Site Scripting (XSS) issues that could allow remote authenticated attackers to inject arbitrary web script or HTML via C__MONITORING__CONFIG__TITLE, SM2__C__MONITORING__CONFIG__TITLE, C__MONITORING__CONFIG__PATH, SM2__C__MONITORING__CONFIG__PATH, C__M...