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.

Operations

4/26/2021
10:00 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Shift Left: From Concept to Practice

By moving security into development, your team can find and fix vulnerabilities before they become expensive, difficult, and publicly embarrassing problems.

With the expansion of the DevOps and DevSecOps models, the concept of "shifting left" in the software development life cycle (SDLC) has become popular. Shifting key operational and security actions earlier in the cycle allows detecting vulnerabilities as early as possible. This has significant value, as the later a vulnerability is discovered, the harder and more costly it is to remediate.

To embrace this, organizations need to integrate security checks and vulnerability detection into every step of the SDLC, rather than thinking of them as gates. Shifting left is about making security more developer-centric and providing security feedback while they are coding.

Related Content:

Top 5 'Need to Know' Coding Defects for DevSecOps

Special Report: How Data Breaches Affect the Enterprise

New From The Edge: The CISO Life Is Half as Good

Why Move Security to Development?
Shift-left security is key to delivering quality software at speed. Instead of running security audits at the end of the SDLC, shift-left makes security an integral part of everyone's job: developers, operations, and application security or threat response teams.

Security tasks should be automated and integrated within the development and deployment pipeline. Automated scans must happen at each incremental change at the exact moment they are written so that:

  • Vulnerabilities are not discovered late in the development cycle.
  • Developers and operations are quickly notified whenever potential vulnerabilities are committed, enabling them to quickly detect and correct security issues within their daily work.
  • Developers can rapidly learn from their errors and apply best practices concerning code hygiene.

By better integrating application security objectives into daily work, teams can achieve higher levels of software delivery performance and build more secure applications. This helps build accountability among non-security team members.

Developers may be concerned that security scans will add extra work and slow deployments. This is reasonable, knowing the pressure on development teams to produce code fast. But developers are also eager to improve the quality and security of their work.

But shift-left detection can ease those concerns by integrating and automating security scans within existing tools and processes. Additionally, there's no release-day stress when the security team blocks the release because of a vulnerability the developer didn't know about.

A developer-centric approach allows developers to respond to alerts as they code. Real-time is far better than days later at deployment — or months later in a penetration test report. This is critical in terms of vulnerability exposure and cost of remediation. It is critical to prevent breaches before they can affect the company's security and to quickly address and fix newly discovered vulnerabilities.

Putting Shift Left Into Practice With Secrets Detection
Application security relies on detecting different types of vulnerabilities in the OWASP DevSecOps Maturity Model, including stored secrets. Indeed, automating detection of secrets puts shifting left into practice.

Because developers work with code and in Git, it is logical to apply security controls in Git. Looking at secrets leaks, shifting left means automatically detecting secrets in the code and allowing the different members of the SDLC to collaborate.

Remediating secrets leaked in Git repositories is a shared responsibility among developers, operations, and application security (if the secret is exposed in internal code repos) or threat response (if the secret is exposed externally). The processes depend on the organization's size, culture, and how it splits responsibilities among teams.

They all need one another, but developers are on the front line. They often know what the leaked secret gives access to. However, they can't always revoke the secret alone because it might affect production systems or fellow developers using the same credentials. Also, it's not only about revoking; it's also about redistributing (rotating), which falls under operations' responsibilities.

While remediating, it is also important to keep security professionals' eyes on the issue. They can guarantee that proper remediation steps are followed and guide and educate developers on the risks. Developers don't always understand the real impact of their actions. For security professionals, alerts must be actionable with as few false positives as possible to avoid alert fatigue.

Remediation is a shared responsibility requiring multiple inputs and multidirectional communication. The right collaboration tools help ensure that information can be gathered from different stakeholders.

Where to Implement Automated Secret Detection
The earlier a security vulnerability is uncovered, the less costly it is to correct. Hard-coded secrets are no exceptions. If the secret is uncovered after it reaches centralized version control on the server side, it's considered compromised. This requires rotating (revoking and redistributing) the exposed credential, which can be complex and involve multiple stakeholders.

Client-side secrets detection early in the SDLC is nice for preventing secrets from entering the version-control system (VCS). Server-side secrets detection is a must-have because that's where the ultimate threat lies. From the server, the code can uncontrollably spread in a lot of different places with the hard-coded secrets in it.

The issue with client-side tooling is the complexity of deployment: The larger the development team, the more complex it is. Implementing client-side hooks on an organizational level is hard. Many application security professionals claim they are not confident to do it because of the difficulty of deploying and updating every developer's workstation. It is also a non-coercive solution: Client-side hooks can and must be easy to bypass. Client-side hooks are largely the individual developer's responsibility — hence, the need to have visibility over later stages.

Empower Developers; Improve Security
Shifting left allows teams to continuously test even small, incremental code changes and avoids a huge amount of work at the end of the SDLC. Integrating security scans and tests at each step of the development process reduces the organization's vulnerability surface.

Shifting left implies automating security as much as possible and empowering developers with a fast, continuous security feedback loop. Scan results should be straightforward and actionable and the process fully automated. Alerts need to be relevant and limit false positives. Even remediation should be facilitated and automated wherever possible.

It helps to build a culture where security is rewarding and respects developers' time. Developers want to create secure code without becoming security experts; security experts want secure code that leverages developers' knowledge during remediation.

Mackenzie Jackson is the developer advocate at GitGuardian. He is passionate about technology and building a community of engaged developers to shape future tools and systems. View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Enterprises are Attacking the Cybersecurity Problem
Concerns over supply chain vulnerabilities and attack visibility drove some significant changes in enterprise cybersecurity strategies over the past year. Dark Reading's 2021 Strategic Security Survey showed that many organizations are staying the course regarding the use of a mix of attack prevention and threat detection technologies and practices for dealing with cyber threats.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2011-4126
PUBLISHED: 2021-10-27
Race condition issues were found in Calibre at devices/linux_mount_helper.c allowing unprivileged users the ability to mount any device to anywhere.
CVE-2011-4574
PUBLISHED: 2021-10-27
PolarSSL versions prior to v1.1 use the HAVEGE random number generation algorithm. At its heart, this uses timing information based on the processor's high resolution timer (the RDTSC instruction). This instruction can be virtualized, and some virtual machine hosts have chosen to disable this instru...
CVE-2020-7867
PUBLISHED: 2021-10-27
An improper input validation vulnerability in Helpu solution could allow a local attacker to arbitrary file creation and execution without click file transfer menu. It is possible to file in arbitrary directory for user because the viewer program receive the file from agent with privilege of adminis...
CVE-2021-26610
PUBLISHED: 2021-10-27
The move_uploaded_file function in godomall5 does not perform an integrity check of extension or authority when user upload file. This vulnerability allows an attacker to execute an remote arbitrary code.
CVE-2021-32951
PUBLISHED: 2021-10-27
WebAccess/NMS (Versions prior to v3.0.3_Build6299) has an improper authentication vulnerability, which may allow unauthorized users to view resources monitored and controlled by the WebAccess/NMS, as well as IP addresses and names of all the devices managed via WebAccess/NMS.