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
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
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
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-2020-16632
PUBLISHED: 2021-05-15
A XSS Vulnerability in /uploads/dede/action_search.php in DedeCMS V5.7 SP2 allows an authenticated user to execute remote arbitrary code via the keyword parameter.
CVE-2021-32073
PUBLISHED: 2021-05-15
DedeCMS V5.7 SP2 contains a CSRF vulnerability that allows a remote attacker to send a malicious request to to the web manager allowing remote code execution.
CVE-2021-33033
PUBLISHED: 2021-05-14
The Linux kernel before 5.11.14 has a use-after-free in cipso_v4_genopt in net/ipv4/cipso_ipv4.c because the CIPSO and CALIPSO refcounting for the DOI definitions is mishandled, aka CID-ad5d07f4a9cd. This leads to writing an arbitrary value.
CVE-2021-33034
PUBLISHED: 2021-05-14
In the Linux kernel before 5.12.4, net/bluetooth/hci_event.c has a use-after-free when destroying an hci_chan, aka CID-5c4c8c954409. This leads to writing an arbitrary value.
CVE-2019-25044
PUBLISHED: 2021-05-14
The block subsystem in the Linux kernel before 5.2 has a use-after-free that can lead to arbitrary code execution in the kernel context and privilege escalation, aka CID-c3e2219216c9. This is related to blk_mq_free_rqs and blk_cleanup_queue.