DEVOPSdigest

The term "shift left" has been thrown around by the AppSec industry for years. "Left" refers to the earlier stages of the development process when depicted in a traditional waterfall process that begins with planning and ends with operations, and usually takes several months to complete. Traditionally, security testing was done near the end of this process, by dedicated security engineers, rather than the development team. Thus, "shifting left" meant moving security testing earlier in the development process, often automating into CI/CD. It can also include giving developers security tools to test their applications as they build.

The concept is a good one. The shorter the gap between adding a vulnerability and finding it, the cheaper it is to fix. But today, in the DevOps era, shifting left isn't quite as clear. Two key parts are missing.

The Left-To-Right Process Is Infinite

Firstly, there is no "left" in the continuous process that essentially does not end. The reason the DevOps process is often depicted as an infinite loop is because, well, it is one. The most innovative companies have realized that a process of rapid iteration, with smaller changes and enhancements, deployed quickly — often multiple times per day — will produce better results over time. Deploying small changes, and then observing the effect, allows these companies to be much nimbler and provide better digital experiences to customers.

However, this model does not leave room for a lengthy security testing phase. Automating security testing into the CI/CD process is a good step because it can prevent critically severe vulnerabilities from being deployed — by "breaking the build" if one is detected. But even though that is a bit late in the process, the developers have already checked in their code and are ready to move on to the next step. Breaking the build too often will become disruptive, so it should be reserved for the most critical vulnerabilities. But letting too many vulnerabilities through to avoid breaking the build isn't a good option either. Security needs to be built into the overall process rather than just one step — no matter how "left" that step is.

Secondly, the shift left doesn't reflect the change in ownership and drive for independent teams. The truly important change isn't whether you shift security testing, but rather, whether you shift the ownership of security to the developers. Pipeline tests that require security teams to review their results, either from false positives or required expertise, are also disruptive to the development process. Each developer team should be equipped and empowered to test for security issues as they work, and where they work — as they code in their IDEs, merge in repositories, and build in CI/CD, adapting to their workflows and skills. This doesn't involve handing developers a list of issues to remediate or giving them a tool designed for the security team. That causes friction and is likely to lead to developers failing to adopt the tools. They need developer-friendly tooling and the ongoing support of the security team, working in tandem toward one common objective.

So what does the shift left mean in 2022, in the midst of a digitally transforming world and where every company is essentially a technology company?

Application Security in the Digitally Transforming World

In today's environment, the shift-left strategy is something every enterprise is embracing for application security, which essentially involves putting security controls in at earlier stages of development. It's a nip-the-problem-in-the-bud approach where security controls in their respective domains highlight potential security weaknesses related to vulnerabilities in code, vulnerabilities in third-party packages and code-quality issues. It also allows security to keep pace with agile development methodologies while managing new risks introduced by cloud technologies.

However, if you have to pick a direction, you should focus less on shifting left and more ongoing top to bottom. This means replacing a controlling, dictatorial security practice with an empowering strategy. One where developers are able to move faster whilst simultaneously reducing the risk of deploying broken infrastructure. Security should not be viewed as a tool that slows things down, but rather as a key aspect of the development process that enables developers to ship secure, reliable solutions without too much trouble.

Moving testing earlier in the process, essentially left, does not help organizations scale. The most tech-forward companies in the world are setting the pace through rapid iteration and multiple deployments each day. Moving left will identify problems earlier, but can increase the backlog of vulnerabilities that require addressing. To move at scale and in sync with the cloud, a top-to-bottom approach focused on three changes called dev-first security should be implemented.

Empowering Developers to Build Securely Through the Entire Process

The dev-first approach to security requires organizations to move security into the heart of the development delivery life cycle, changing ownership of actions and adjusting existing attitudes towards security. The mindset that "developers build" and "security secures" must be adjusted as it does not and will not work in the digital era. Developers should be encouraged to move fast and directly provision applications to the cloud through existing applications by removing manual processes and the need for additional IT assistance. Developer teams need to have access to all the pieces of security controls that, as of today, are being built into the pipeline.

To further modernize the shift-left approach to security, responsibilities must be passed on to those creating software. Continuous security must be integrated throughout, starting as far left as the Integrated Development Environment (IDE) where the code is built, extending all the way into monitoring applications and production once deployed. This way vulnerabilities are found as early as possible when it is the easiest and least costly to fix them, which is where and how you scale security.

App development is so critical to every company's success these days — getting new apps and capabilities delivered to drive strategic goals. This approach to security supports the pace of innovation that is too fast for security alone to handle. With the scale of developer teams compared to security currently sitting at 8 to 1 per company, security teams must be given the tools to make developers successful during the development process.

This approach doesn't involve companies skimping out on security and focusing solely on developers, but maintaining security as the overarching goal for each department including the CISO and those working across AppSec, DevSecOps and ProductSec.