Shifting security left requires a GitOps approach

The shift-left concept

The concept of shifting left isn't new. In the early 2000s, software developers typically used waterfall development processes where testing occurred later in the software development lifecycle -- usually right before deployment. The phrase shift-left testing was coined in 2001 to encourage testing early and often in the development process. The goal is to improve planning by catching issues early instead of building on top of flaws, as well as reducing the time to fix any discovered coding defects.

Developers today use agile processes with continuous integration and continuous delivery (CI/CD) pipelines for faster cycles and a higher volume of releases. DevOps has also shifted IT and operations responsibilities left, enabling developers to provision their own cloud infrastructure and manage computing resources without the help of IT or a sys admin.

Security has yet to see the same shift-left success. While many developer-focused security tools are available, developers often use them inconsistently. What may be suitable for smaller organizations isn't scalable as businesses grow -- it's hard to ensure consistent security practices across larger development teams.

At the same time, it's difficult for security teams to get visibility into development. Security teams have products to monitor security issues in runtime, but by the time they catch misconfigurations, they're already in production where customers or hackers can find them. In this scenario, the security team must track the problem back to the developer and work with them to remediate the issue.

Security teams want to shift security testing left to prevent coding flaws from being deployed; however, they're encountering challenges with developers and within their own teams.

Challenges of shift-left security for developers

Product development is about delivering high-quality products on time. In the cloud-native world, the ability to release products and updates efficiently brings a competitive advantage. But coding flaws, including simple mistakes and misconfigurations, can have serious consequences, such as exposing data or causing systems downtime. It is in a developer's best interest to test early and fix issues, just as they would perform unit testing on their code to test for functionality.

Developers may indeed be using security tools before releasing code to production. Hundreds of free and open source security testing tools are available, for everything from infrastructure as code and container images to Kubernetes and software component analysis. Cloud security providers also offer features and capabilities to automate security testing.

But developers may not be experienced or knowledgeable about security testing, despite an abundance of tools. Staying on top of available tools is hard; many are difficult to use and they can produce an overwhelming number of alerts. Plus, developers don't want to become security experts or get more work -- especially if it slows down development processes.

Developers need testing that runs automatically in the background without hindering processes. Tools must work within their integrated development environment (IDE) so there is no context switching needed for developers to remediate coding flaws when they are detected by a security tool.

Challenges of shift-left security for security teams

As companies adopt modern development processes, security teams need to figure out how to scale security at the speed and volume of releases. Security team members are typically outnumbered by developers. Interacting with each developer to run security testing is impossible. Plus, security teams don't want to hold up processes with bottlenecks.

Security teams often lack visibility into what testing developers have done before an application is deployed. It is critical for security teams to gain visibility and control by consistently applying policies to reduce risk, and to ensure developers test and fix misconfigurations before deploying their applications.

Security teams also need to partner with development. If security has no authority to roll out security products or set up security policies for developers to use, they have no way to gain the visibility and control needed to reduce risk.

And even if security has the authority to work with development to use the right security tools, if the tools disrupt developer workflows or if security teams try to use products that cause too much work, developers become reluctant to perform security testing.

Achieving the right balance to successfully shift left

Shifting left isn't about pushing security work left to developers. It's about adjusting roles and expectations with the right tools in place. Security teams are still responsible for managing risk. Ultimately, their job is to meet regulatory requirements, reduce the chance for attacks, and protect company and customer data from breaches. But security teams can help enable developers to take a more active part in the process by making developers responsible for testing their own code.

Security teams should set up policies as guardrails to reduce misconfigurations. They should also select testing tools that are easy for developers to use and that won't overwhelm developers with false positives or alerts for code issues that don't need fixing. Tools need to be simple to set up and should communicate directly with developers within their IDEs. Security teams can, for example, give developers instructions on how to connect testing tools or products to their CI/CD pipeline. Useful tools, once connected, can automatically scan the code in the background without disrupting development and automatically scan again upon any code changes.

Developers are accepting of easy-to-use, nondisruptive tools. They want faster feedback loops for correcting coding flaws, and they want to be confident they are deploying secure and reliable software.

Shifting left has been a challenge. The right tools have only recently emerged. Too often, security teams have purchased products only to see them end up as shelfware because developers didn't want to be forced to use them. Newer products can orchestrate testing for developers while sending the data to security teams so they can gain visibility into the testing and analysis.

The measurable benefits of shifting left

Shift-left security tools should provide measurable results. They shouldn't push more work to security teams or developers, but rather reduce workloads for both.

With security integrated into developer workflows, security teams have better visibility and control. Security teams should also see fewer misconfigurations deployed into production, as well as reduced mean time to remediation. Developers should be able to efficiently fix flaws as they are discovered -- and before going into production -- with shift-left security tools, giving them faster feedback loops and more secure applications.

Enterprise Strategy Group (ESG) is a division of TechTarget.