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.


// // //
10:00 AM
Connect Directly
E-Mail vvv

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
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
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
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
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
Current Issue
Everything You Need to Know About DNS Attacks
It's important to understand DNS, potential attacks against it, and the tools and techniques required to defend DNS infrastructure. This report answers all the questions you were afraid to ask. Domain Name Service (DNS) is a critical part of any organization's digital infrastructure, but it's also one of the least understood. DNS is designed to be invisible to business professionals, IT stakeholders, and many security professionals, but DNS's threat surface is large and widely targeted. Attackers are causing a great deal of damage with an array of attacks such as denial of service, DNS cache poisoning, DNS hijackin, DNS tunneling, and DNS dangling. They are using DNS infrastructure to take control of inbound and outbound communications and preventing users from accessing the applications they are looking for. To stop attacks on DNS, security teams need to shore up the organization's security hygiene around DNS infrastructure, implement controls such as DNSSEC, and monitor DNS traffic
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
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences. Cross site scripting (XSS) can be triggered by review volumes. This issue has been fixed in version 4.4.7.
PUBLISHED: 2023-05-26
Django-SES is a drop-in mail backend for Django. The django_ses library implements a mail backend for Django using AWS Simple Email Service. The library exports the `SESEventWebhookView class` intended to receive signed requests from AWS to handle email bounces, subscriptions, etc. These requests ar...
PUBLISHED: 2023-05-26
Highlight is an open source, full-stack monitoring platform. Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `ty...
PUBLISHED: 2023-05-26
Craft is a CMS for creating custom digital experiences on the web.The platform does not filter input and encode output in Quick Post validation error message, which can deliver an XSS payload. Old CVE fixed the XSS in label HTML but didn’t fix it when clicking save. This issue was...
PUBLISHED: 2023-05-26
GDSDB infinite loop in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via packet injection or crafted capture file