With the expansion of the DevOps and DevSecOps models, the concept of “shift left” in the context of the development lifecycle has become quite popular. Shifting key operational and security actions earlier in the cycle allows detecting vulnerabilities as early as possible. This has a significant value as the later a vulnerability is discovered, the harder and therefore more costly it is to remediate.

Pushing testing earlier in the cycle (shift left testing - getting as far on the left as the planning phase, where acceptance tests should be written) and spreading it in every step may sound simple, yet has strong implications. It means that testing cannot be considered as a separate activity anymore but has to be injected everywhere (continuous testing). More globally, it also means that what is needed is a culture shift: teams should be encouraged to collaborate and to reduce friction in order to build trust and a shared sense of responsibility in the development process.  

For organizations to truly embrace this concept they need to consider security checks & vulnerability detection not as a gate but integrate it into every step of the development lifecycle. Shifting left is about making security more developer-centric, and giving developers security feedback where they are, when they are coding.

A good example of shift left testing put into practice is the implementation of automated vulnerability detection at each incremental change made by developers, and as we have experience with secrets detection we will explain how it serves this purpose.

Why move security to the development phase?

Shift left security is the key to delivering quality software at speed. With shift left testing instead of running security audits at the end of the software development cycle, security becomes an integral part of everyone’s job: developers, operations, and of course application security or threat response teams.

Security tasks need to be automated and deeply integrated within the development and deployment pipeline. Automated scans need to happen at each incremental change, at the exact moment they are written.

They will ensure 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 as part of 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. It helps to build accountability among non-security team members.  

The Cloud Security Alliance (CSA) put it very clearly: “Security can be achieved only  when it has been designed in. Applying security measures as an afterthought is a  recipe for disaster”.

Developers are oftentimes concerned that security scans will add extra work and slow down their deployments. This is a reasonable concern knowing the amount of pressure that is put on development teams to produce code fast. But developers are also eager to improve the quality and security of their work.

But with shift left detection, you can ease those concerns because the security scans are integrated and automated into the developer’s existing tools and agile processes. Consequently, there’s no release day stress when the security team blocks the release because of a vulnerability the developer didn’t know existed.

A developer-centric approach allows them to stay in context and respond to alerts as they code.  Real-time is far better than days later at deployment or months later from a penetration test report. And this is critical in terms of vulnerability exposure and cost of remediation. It is very important to prevent breaches before they can impact the company’s security, and to move quickly to address newly discovered vulnerabilities and fix them.

Application security relies on detecting different types of vulnerabilities, they are listed in the OWASP DevSecOps maturity model. Stored secrets are included at the basic level. So let’s look at how secrets detection automation really means shift left put into practice.

The case of secrets detection

In practice, developers work with code and in git, so it is logical to apply security controls in git. Looking at the specific issue of secrets leaks, shifting left will mean putting in place a tool capable of automatically detecting secrets in the code but also allowing collaboration of the different actors of the development life cycle.

Indeed, remediating secrets leaked in git repositories is often a shared responsibility between developers, operations, and application security (if the secret is exposed in internal code repos) or threat response (if the secret is exposed externally). Of course, the processes to put in place depend on the size of the organization, the way responsibilities are split between teams, and its culture.

But they all need one another. Developers are on the front line. They often know what the leaked secret gives access to.

On the other hand, they can’t always revoke the secret by themselves, because it might impact production systems or fellow developers using the same credentials. And 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 the eyes of security professionals on the issue because such professionals guarantee that the proper remediation steps are followed, and they can guide the developers through them and educate them on the risks. Developers don’t always understand the real impact of their actions. For the security professionals, alerts must be actionable with as few false positives as possible to avoid alert fatigue.

It is therefore important to equip everyone with the right collaboration tools so that information can be gathered from the different stakeholders. Remediation is a shared responsibility requiring multiple inputs and multi-directional communication.

Where in the SDLC should automated secret detection be implemented?

The earlier a security vulnerability is uncovered, the less costly it is to correct. Hardcoded secrets are no exceptions. If the secret is uncovered after the secret reaches centralized version control server-side, it must be considered compromised, which requires rotating (revoking and redistributing) the exposed credential. This operation can be complex and typically involves multiple stakeholders.

Client-side secrets detection early in the software development process is nice to have as it will prevent secrets from entering the VCS.

Server-side secrets detection is a must-have. Server-side is where the ultimate threat lies. From the server, the code can uncontrollably spread in a lot of different places, with the hardcoded secrets in it.

The issue with client-side tooling is the complexity of deployment: the larger the development team is, the more complex it is. Implementing client-side hooks on an organization level is hard. This is something many application security professionals claim they are not confident to do, due to the difficulty to deploy and update this on every developer’s workstation. It is also a non-coercive solution: client-side hooks can and must be easy to bypass. Usage of client-side hooks largely comes down to the individual developers’ responsibility.  Hence the need to have visibility over the later stages.

Conclusion

Shifting left by implementing a secret detection solution allows to continuously test even small, incremental code changes. A huge amount of work is avoided at the end of the SDLC. Development, operations, and security teams can integrate security scans and tests at each step of the development process, thereby reducing the vulnerability surface of their organization.

“Shifting left” implies automating security as much as possible and empowering developers with a better understanding of security through 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 the number of false positives

Even remediation should be facilitated and automated wherever possible.

It helps to build a culture where developers want to do the right thing as security becomes rewarding and is done respecting their time.

Developers want to create secure code—without becoming security experts; Security experts want secure code leveraging developer knowledge during remediation.