Shift Left: From Concept to Practice

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.

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:

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.