Why you must shift left security in the software development lifecycle

In a world that’s becoming increasingly digital, the security of software and applications that users interact with is a recurring and crucially important theme. The risks, and impact, of security breaches coming from applications that breach user data are increasing constantly, and the monetary costs of breaches to organizations warrant continued investment in application security tooling, awareness and processes.

In the DevOps world, a key focus advocated by industry experts is implementing DevSecOps as a practice, where application security testing is integrated into the development process, rather than as an afterthought when a product is being released.   DevSecOps approaches advocate that development and security teams work together to find and address security flaws much earlier in the software development lifecycle – since they are cheaper to fix and address.

And it makes sense for security teams to implement application security testing, practices, automation and tools to the code creation and production stages, so that it’s no longer an afterthought, but something developers and DevOps engineers are aware of to create secure code and production systems.

This practice of integrating application security testing into the development and operational phases is called shifting security left, where left means earlier in the process. In effect, developers and security both jointly own responsibility to find and address security vulnerabilities and coding mistakes much earlier in the software development lifecycle. What is different is that the teams take joint responsibility, developers taking the lead to find and fix security vulnerabilities earlier in the development lifecycle, and security engineers helping with that process.

Security Teams don’t scale, so shift left security

A key driver in shift left security testing is that most organizations have far fewer security engineers than software engineers. Waiting until the end of the software development process to throw code over the wall to Security teams to run security tests on hasn’t worked in the past, and certainly won’t work in this cloud-native and microservices-based world. These teams are security domain experts, not experts on the code developers write, the technologies that applications are packaged with and the cloud environments applications are deployed in. And while they certainly run “point in time” security checks on code written by developers, that’s a manual, very sequential and interdependent way of doing work.  These point in time approaches to security scanning is also a significant inhibitor to the goal of releasing software continuously.

DevSecOps: the new normal or just more tools?

The goal of DevSecOps – shift left security testing and analysis to earlier in the dev lifecycle, using automation and integrating security and engineering teams together is a fantastic starting place.  The problem is that this can also lead to a proliferation of tools and tool chains that increase complexity and make it difficult to understand full lifecycle security analytics.

Consider that to fully address application security, teams are asked to run Static Analysis Tests of their source code, Dynamic Analysis Tests of compiled binaries, Container Security Tests to ensure new vulnerabilities or secrets aren’t exposed in packaging technologies, Software Composition Analysis to ensure that included open source libraries do not add in new vulnerabilities into the application, and Interactive Application Security tests to check against various attack scenarios that applications are exposed to when deployed in different cloud environments.  The multiple testing approaches and tools used increases complexity, extends, rather than shortens cycle time, and prohibits the collection and analysis of full application security lifecycle analytics, needed by organizations to release software with more confidence.

So how do you make sure that multiple security tests and tools don’t make pipelines come to a grinding halt and frustrate both your software development and security teams?

Seamless Security

The key is to not only integrate security tools into the software development lifecycle and the CI/CD pipelines, but to make the experience seamless, for the developer, DevOps engineer and security team.

And seamless is more about the experience, than any individual component. By creating elevating the CI/CD pipeline experience from a disjointed, fragmented experience to a seamless experience with continuous feedback loops of information, security teams get exactly the right insights into the security posture of new code, while developers get instant feedback on how to improve their code, without wasting time or context switching.

As an example, take GitLab’s seamless security experience. It’s CI product enables security testing before code leaves the individual developer’s local environment, and any security improvements are directly fed back to the developer for immediate improvements.

This serves two purposes:

1. The immediate feedback helps developers improve their code and teaches them to write ever more secure code.
2. It frees up the security team, so they can focus on security aspects outside of the software development lifecycle, while they still have a way of measuring and tracking progress of secure in the pipeline.

The result is that a developer’s pipelines and workflow now have various security measures integrated, from static and dynamic code checking, dependency scanning and container scanning, with immediate feedback on improvements a developer can implement to remediate security issues.

Other benefits

There are more benefits than outlined in this blog post; there are simply too many to dive into in a single blog post:

Benefits to the business

• Every piece of code is tested upon commit, without incremental cost.
• One source of truth for both development and security promotes collaboration and empowers the developer to identify vulnerabilities within their own workflow.
• Vulnerabilities can be efficiently captured as a by-product of software development.
• A single tool also reduces cost of buying, integrating, and maintaining point solutions.

Benefits to the security organization

• Developers can remediate in real time so security professionals can focus on the vulnerabilities that cannot be easily fixed by the developer.
• An integrated security dashboard displays a roll-up of unresolved vulnerabilities and metrics overall.
• Security can drill-down from the dashboard to see the code itself, and make comments, simplifying collaboration with the developer.

If you want to know more, check out A Seismic Shift in Application Security, which goes into how to shift left security in more detail.