Cloud Hosting

In covering cloud-native security, a lot of people use the terms shift left or shift-left security. A few weeks ago at RSA Conference 2023, the concept got plenty of buzz. And while it's sometimes used correctly, I often hear it misused or criticized based on misconceptions.

For example, when I hear things like "don't shift left," "shift right," or "shift left but shield right," it's problematic in terms of how we need to think about security for cloud applications. When I released my 2022 report "Walking the Line: GitOps and Shift Left Security" to cover developer-focused security products and services, the title was meant to be provocative in terms of examining how far organizations have been able to shift left, what their top challenges are and what they need to be successful.

So, let's clear this up: What does shifting left really mean, and how do we need to approach cloud security?

The term shift-left security comes with the move to cloud-native development. By using cloud platforms for IaaS or PaaS, it's easier for developers to quickly and efficiently build software applications.

It enabled operations to shift left for DevOps, so instead of developers needing to work with or wait for IT or operations to set up computing infrastructure -- virtual machines, servers, hardware -- we shifted operations left to empower developers to provision their own infrastructure so they could easily build their applications and deploy them to the cloud.

With DevOps processes in place, organizations could scale development for faster release cycles and updates. But then security became the bottleneck.

With DevOps processes in place, organizations could scale development for faster release cycles and updates. But then security became the bottleneck. Developers don't want to wait for security teams to perform testing, and they typically don't want to hear from security teams about problems they need to fix.

The cure should be simple: Just shift security left to developers. We shifted ops left to developers to scale, so why not shift security left?

Understanding the need to shift security left to developers, security vendors started building tools for developers to use. But developers didn't want to use them because they weren't made for developers.

Instead, developers began creating their own security tools made for software engineers, often sharing them as open source tools. For organizations that didn't have staff with the expertise or time to create custom tools, why buy security tools when they could use popular, free open source tools like Trivy for vulnerability scanning, Checkov for scanning infrastructure as code (IaC), or Open Policy Agent for setting policies? My research showed that developers most often use custom tools, open source or features from cloud service providers to secure their cloud-native applications.

While developers were finding security tools they could use to find coding issues earlier in their development processes, security teams didn't have visibility or control into the tools or processes developers were using. Also, for organizations with multiple development teams, consistency is challenging because developers have varying skills and experience with security.

Meanwhile, security teams have struggled to gain visibility or control of the tools or processes developers are using. While they can use cloud security posture management (CSPM) tools to monitor cloud applications and workloads for vulnerabilities and misconfigurations, they only have visibility in runtime. This means the issues are deployed in the applications running in the cloud, with exposure to customers, partners, employees and potential attackers.

The above scenario isn't effective because it can't scale. The results of my research showed the top challenges for security include software being released without going through security checks or testing (according to 45% of organizations), security lacking visibility and control in the development process (43%), and lack of consistency across development teams (36%). A full 97% of organizations faced a variety of security incidents resulting from insecure API use, code vulnerabilities, access issues and misconfigured cloud services, among other causes.

This brings up complaints about shift-left approaches not being effective. This has more to do with the evolution of security tools mentioned above, however, where you have developers taking on security tasks earlier in the development process, which is good. But then you have security only having visibility and control in runtime, which is inefficient and difficult to manage.

This leads to misconceptions and problems with the words shift and left. Shift implies moving or shifting security responsibilities. Yes, security needs to shift more responsibility and tasks to developers, but security is still on the line for securing cloud applications. Security roles change from doing all the security tasks, which simply cannot scale with the speed and volume of releases, so it is essential for developers to take on more of the security responsibilities so security teams can focus instead on risk mitigation and rapid response to threats or attacks.

The word left has also become associated with the left side of the software development lifecycle (SDLC). It's better to incorporate security as early as possible in development. If developers can incorporate security processes, such as setting policies and performing testing, they can catch and fix issues early -- ideally before they release their applications. But it doesn't end there. In runtime, when security issues are detected, developers need ways to quickly and efficiently fix their code without having to deal with a security bottleneck.

We need to clear this up. Shifting left is about empowering developers to better secure their applications, freeing up security teams to scale to better support them. Security teams need to work with development throughout the SDLC to drive efficiency for remediation -- which is what is needed for both teams.

Part of the problem is that we need to change how we think of security for cloud-native applications and modern software development processes. With traditional application development, we had linear, left-to-right product development processes from building, to testing, to staging, to releasing to production. We had longer development cycles where we could conduct security testing and quality assurance before software releases.

Now, with modern development processes, we have continuous integration/continuous delivery pipelines, where we have better collaboration to build our cloud infrastructure and applications, rapidly deploy them to the cloud and continuously update them. So, it's no longer linear; it's just build, deploy and continuously update. It has evolved into an infinity circle (more to come on this topic).

What this means for security is that we have to stop thinking of a "left side" and a "right side" of the software development process. The benefits of moving to cloud-native applications are all about efficiency. Security needs to work closely with developers and their continuous workflows to better enable them to secure their applications.

The problem is that we are used to selecting tools for security teams to use, and we are used to concepts like ensuring we have coverage to scan all things and get alerts so we can fix the issues. With this mindset, security teams won't keep up as their organizations move to the cloud for digital transformation.

Instead, organizations need to shift security left the right way -- by talking to developers, incorporating security processes and tools throughout the SDLC for developers to use, and shortening feedback loops for remediation. Then, security teams can shift security tasks to developers, while gaining visibility and control to focus their work on mitigating risk and ensuring efficient responses to attacks or threats.

Read the rest here:
Addressing the confusion around shift-left cloud security - TechTarget