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
Florida Town Pays $600K to Ransomware Operators
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/20/2019
Pledges to Not Pay Ransomware Hit Reality
Robert Lemos, Contributing Writer,  6/21/2019
AWS CISO Talks Risk Reduction, Development, Recruitment
Kelly Sheridan, Staff Editor, Dark Reading,  6/25/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
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-1619
PUBLISHED: 2019-06-27
A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to bypass authentication and execute arbitrary actions with administrative privileges on an affected device. The vulnerability is due to improper session ...
CVE-2019-1620
PUBLISHED: 2019-06-27
A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to upload arbitrary files on an affected device. The vulnerability is due to incorrect permission settings in affected DCNM software. An attacker could ex...
CVE-2019-1621
PUBLISHED: 2019-06-27
A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to gain access to sensitive files on an affected device. The vulnerability is due to incorrect permissions settings on affected DCNM software. An attacker...
CVE-2019-1622
PUBLISHED: 2019-06-27
A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to retrieve sensitive information from an affected device. The vulnerability is due to improper access controls for certain URLs on affected DCNM software...
CVE-2019-10133
PUBLISHED: 2019-06-26
A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The form to upload cohorts contained a redirect field, which was not restricted to internal URLs.