Shifting Security Left: Tools and Best Practices

What Is Shift Left Security?

Software development pipelines typically cycle through key four processes—design, development, testing and software or update releases. Traditional pipelines perform quality and security tests only after completing the development phase. 

Since there is no such thing as a perfect code, there are always issues to fix. However, if significant architectural changes are needed, fixing them at the end of the process can be highly expensive. 

Once issues are detected, it can take a long time to assess the situation and design appropriate remediation. This is made significantly more difficult when a development team is working on complex production systems, which often accumulate a series of interconnected problems.

Shifting security to the left means introducing security checks and work during the development phase. The goal is to ensure that the codebase is designed to be secure from the start, rather than checking for security issues at the end of the process. This often requires automating certain aspects of the process.

Integrating Security Into the Feedback Cycle

A central part of the DevOps process is enabling rapid feedback to developers and operations teams, enabling them to adapt systems to user requirements. Part of shifting left security is integrating it into this feedback loop—ensuring that security issues are visible to all members of the team, during all stages of the software development lifecycle (SDLC).

Modern development teams should have visibility over vulnerabilities and weaknesses in builds, from the moment a developer commits code to a repository. Automated security testing makes it possible to alert developers of any security issues in their code, long before the code is deployed. 

Later in the process, when builds are deployed to a testing environment, teams should have continuous monitoring and alerting in place for all applications and infrastructure. During planning meetings, both operations and security staff can evaluate security concerns, and work together to develop a cohesive testing framework.

Finally, during production, security issues should raise alerts that are visible not only to security teams, but also to operations and developers. A security alert should tie the incident back to the individual components related to them, so that developers immediately know what to fix. This end-to-end visibility is the embodiment of “shift left” security.

With effective monitoring and alerting, engineering and IT departments can share processes, metrics, logs and dashboards to keep informed of what’s happening in all environments—development, testing and production. Continuous testing, monitoring and alerting, with rapid remediation of security issues, are the basis of a DevSecOps organization.

Shift Left Security Tools

There are numerous ways to shift security to the left, the majority of which involve the introduction of one or more tools into the pipeline. Here are several commonly used tools:

• Static Application System Testing (SAST)—is an automated scan that checks application security. The test scans the source code of the application, trying to detect known vulnerabilities. This test does not require code to be compiled or running. You can run a SAST scan on code in progress, and shift security testing to the left.
• Dynamic Application Security Testing (DAST)—this test looks for vulnerabilities in running applications. To do this, a DAST tool performs fault injection techniques on the application, trying to identify common security issues like SQL injections. DAST tools can also detect runtime errors, like server configuration issues.
• Interactive Application Security Testing (IAST)—a solution that implements DAST and SAST elements simultaneously. IAST is typically deployed as an agent into the runtime environment. The agent can then observe operations and attacks, and identify vulnerabilities.
• Secrets detection—solutions look at the entire history of a project, including all changes made. The goal is to ensure that there are no compromised secrets or vulnerabilities that were not detected by SAST scans, and detect vulnerabilities related to secrets, such as database credentials and application programming interface (API) keys.
• Dependency scanning—is an automated scan that looks for vulnerabilities in dependencies. It is typically implemented during the development and testing phases. You can use dependency scanning to check the open source libraries you are using for known vulnerabilities.
• Runtime Application Self Protection (RASP)—is a tool designed to detect attacks in real-time. RASP is typically configured on a server and starts scanning only when the application starts running. The goal is to protect the application against malicious actors. To do this, RASP tools analyze the behavior of the application within its context.

The Problem of Alert Fatigue

With the proliferation of security tools, more and more security alerts are received at every stage of the development lifecycle—from development through testing, staging and production. Although shifting left brings more teams and departments into the security process, at the end of the day, those who deal with the vast majority of alerts are security analysts.

Today, organizations face a global cybersecurity skills shortage, and in most security teams, time and resources are scarce. Overworked security analysts find it difficult to review, prioritize and deal with the large number of alerts. And if alerts are not handled on time, and real security issues and incidents are missed, this defeats the point of shifting security left. 

There are several solutions that can help you address alert fatigue as your organizations shifts left:

• Reducing false positives—modern security tools use advanced technology like behavioral analysis to identify real security incidents and de-prioritize noise. This reduces the number of alerts and can save significant time for security teams.
• Automating response—security automation tools like Security Automation, Orchestration and Response (SOAR) and eXtended Detection and Response (XDR) can automatically respond to many security events, reducing the load on human incident responders and helping to mitigate threats faster.
• Incident alert management—alert management tools ensure that the most important alerts reach security staff. Platforms like OnPage provide alert escalations, redundancies in case staff do not respond, on-call schedules and “alert-until-read” notifications, ensuring that critical alerts are acknowledged by the relevant team members.

Best Practices for Shifting Security Left

Here are several practices you can implement when shifting security to the left:

• Define a shift-left security strategy—create a one-page document that clearly defines the process. Explain the vision, ownership or responsibility, milestones and metrics used for shifting security left. Keep this strategy simple and dynamic. The goal is to ensure all relevant parties understand the process and their responsibilities.
• Assess where and how software is created—before you can start shifting security left, you need to understand how your development pipeline works. You need to identify who is responsible for developing code, how code moves from development to production, and which technology is used throughout the process.
• Automate security processes—dynamic pipelines require continuous work, which should ideally be supported or entirely performed by autonomous processes. To automate security, you should first assess your existing tooling and then choose relevant tools that can automate the process. You should also test the process and integrate captured results with defect tracking tools.
• Implement security fixes as you develop the code—ideally, you should introduce security into the development process as it occurs, and provide feedback as fast as possible. This way, developers get feedback on the code they are working on, and can quickly implement fixes.
• Develop a culture of visibility—a key goal in shifting security left is to ensure that the code is kept secure during and after its release. To do this, teams need constant visibility into the application performance. They can then remediate as needed by releasing software updates.

Conclusion

In this article, I discussed the importance of the shift left concept in security, and a few tools and techniques that can help you implement it in your organization. Shift left is especially important given today’s breakneck pace of development—in an automated CI/CD pipeline, it simply isn’t possible to start thinking about security at the end of each development cycle. 

By implementing shift left and adopting a DevSecOps mindset, you can foster collaboration and knowledge sharing between developers, operations teams and security experts, and ensure security is “baked into” your product from day one.

FAQs