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
Enterprise Cybersecurity Plans in a Post-Pandemic World
Download the Enterprise Cybersecurity Plans in a Post-Pandemic World report to understand how security leaders are maintaining pace with pandemic-related challenges, and where there is room for improvement.
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-2021-26587
PUBLISHED: 2021-09-27
A potential DOM-based Cross Site Scripting security vulnerability has been identified in HPE StoreOnce. The vulnerability could be remotely exploited to cause an elevation of privilege leading to partial impact to confidentiality, availability, and integrity. HPE has made the following software upda...
CVE-2021-36878
PUBLISHED: 2021-09-27
Cross-Site Request Forgery (CSRF) vulnerability in WordPress uListing plugin (versions <= 2.0.5) makes it possible for attackers to update settings.
CVE-2021-37539
PUBLISHED: 2021-09-27
Zoho ManageEngine ADManager Plus before 7111 is vulnerable to unrestricted file which leads to Remote code execution.
CVE-2021-33907
PUBLISHED: 2021-09-27
The Zoom Client for Meetings for Windows in all versions before 5.3.0 fails to properly validate the certificate information used to sign .msi files when performing an update of the client. This could lead to remote code execution in an elevated privileged context.
CVE-2021-34408
PUBLISHED: 2021-09-27
The Zoom Client for Meetings for Windows in all versions before version 5.3.2 writes log files to a user writable directory as a privileged user during the installation or update of the client. This could allow for potential privilege escalation if a link was created between the user writable direct...