The What, Why and How of Shift-Left Security

We are living in an age of cybersecurity crisis, and shift-left security is part of the solution. Not only are attacks increasing in frequency – the average number of attacks increased by more than 15 percent in 2021, a trajectory that shows no signs of stopping – but threats are also growing increasingly complex. Threat actors are taking advantage of more sophisticated attack methods, such as social engineering attacks, which increased by 270 percent in 2021, and the deployment of “stealth viruses” designed to evade traditional detection methods.

This doesn’t mean, however, that businesses must sit idly by as they face cybersecurity attacks of record-breaking scope and intensity. They can fight back by shifting security “left.” In doing so, they gain the advantages not only of earlier detection of risks, but also of having to invest less time and resources in mitigating threats.

Keep reading for a comprehensive look at what shift-left security means, why it’s valuable and examples of how to shift security left in practice.

What is shift-left security?

Shift-left security is an approach to application security that emphasizes detecting and mitigating security problems as early as possible within the software development lifecycle.

To understand what that means, you must first understand how software development lifecycles (which are also sometimes called software delivery lifecycles or software development pipelines) work in DevOps. Typically, each new application or application version that a team develops passes through a series of stages:

• Coding, which is when code for individual features or units of functionality is written.
• Integration, during which features or changes  are integrated into the main application codebase.
• Building, meaning the process of compiling source code and dependencies into binaries that can be executed.
• Testing, when engineers run tests to validate that applications meet performance requirements.
• Deployment, or the process of putting the application into a production environment.
• Runtime, which is what happens when the application is running in production.

Source: https://jfrog.com/blog/shift-left-security-with-golang-in-vs-code/

Traditionally, security tests took place during the testing phase of the delivery lifecycle. Sometimes, they didn’t happen until an application was already deployed into production. Under a shift-left security methodology, however, DevOps teams begin security testing as early as possible – ideally, as soon as new source is written.

For example, under a shift-left approach, you might scan your source code to identify application dependencies before the code is compiled and staged. With that information, you can determine whether any of the dependencies introduce vulnezrable open source components into your codebase. If left unaddressed, those vulnerabilities would become an active security threat when your application is deployed into production.

As another example, a shift-left strategy could help you to detect misconfigured access controls, which constitute a security risk because they weaken your application’s security posture. If you don’t update your access controls prior to deploying the app into production, you’ll introduce the configuration risks into your production environment.

Shifting security left doesn’t mean that you no longer have to perform security monitoring in production. You should certainly still make every effort to detect threats in production environments. But when you shift security left, you also invest heavily in detecting risks and threats earlier in the development lifecycle. The earlier in the development lifecycle that security issues are resolved, the more cost effective for an enterprise.

The shift-left security concept mirrors shift-left monitoring and testing, which predated the emergence of the idea of shift-left security. Whereas shift-left monitoring and testing involve running performance and reliability tests as early in the software development lifecycle as possible, shift-left testing emphasizes security testing early in the development lifecycle.

The main benefits of shift-left security

Organizations that embrace shift-left security gain several key benefits:

Earlier detection of risks

Perhaps most obvious is the fact that shift-left security helps teams to detect risks early. By extension, it gives engineers more time to react, while also reducing the severity of the threat posed by a risk or vulnerability.

If you discover a zero-day vulnerability in an app that’s in production, you need to take action to solve it immediately, because it could be exploited at any moment. Resolution in this situation often means following the path of least resistance (such as turning off your app until you can update it to fix the vulnerability), rather than applying a less disruptive mitigation. But if you detect the issue during development, you can address it with minimal disruption to your users, and without having to treat it as a crisis situation.

Minimize threats in production environments

Detecting risks and threats earlier in the development lifecycle also significantly reduces the chances that threat actors can exploit a risk or vulnerability within an application.

Although it is possible for attackers to breach the pre-production environments where applications are developed and tested (as they did, for example, during the SolarWinds attack), the risk of active attack is much higher in production environments. In production, applications are exposed to end-users and, in most cases, the Internet, so it is much easier for threat actors to find and exploit vulnerabilities in production than it is in a development or testing environment, which typically is not directly accessible from the Internet.

Fix threats faster and more cost effectively

In general, the earlier you detect a security risk or threat, the less time and effort it takes to address them.

For example, if you catch a security problem before the code has been compiled and moved into testing, you can simply update the code. You won’t have wasted time building and testing an application release that you will end up scrapping. In contrast, if you don’t catch an issue until production, you’ll have to identify the root cause of the threat, update your source code, rebuild your app, test the updated version and, finally, deploy it – a process that could take weeks, whereas updating source code before the app has been built may take just minutes, if the vulnerability is simple to address.

And, because time is money, faster mitigation of issues not only saves developer effort, but also reduces costs for the business. When developers spend more time building new applications and features, and less time fixing security bugs, the business can do more with the coders on staff.

Reduce the risk of delays

The further down the software delivery pipeline you let your code move before detecting a security issue, the higher the risk that the issue will cause a delay in your application release.

Again, security problems that are detected when an application update is still just source code can often be corrected quickly and easily. But if you wait until the application release has already been built – or, worse, until it is in production – fixing the issue becomes a much longer process, significantly increasing the risk that your team won’t deliver the updated app according to its promised timeline.

Improve collaboration between developers and security teams

Detecting security risks and threats earlier, when they are easier to fix and don’t create a crisis situation, also helps to facilitate smoother collaboration between developers and security teams. It’s easy for each of these groups to step back, assess an issue and work collaboratively to solve it when the issue is detected within source code.

On the other hand, if you don’t catch a security problem until production, you’re more likely to end up with developers and security engineers pointing fingers at each other. Developers will blame security for not catching the issue, while security blames developers for introducing it. That’s not a recipe for collaboration.

Shift-left security vs. DevSecOps

The fact that shift-left security makes it easier for developers and security teams to collaborate is one reason why shifting security left often comes up in the context of conversations about DevSecOps – a concept that encourages active collaboration between developers, security teams and IT operations teams.

That doesn’t mean, however, that shift-left security and DevSecOps mean the same thing. DevSecOps is a philosophy or goal that organizations can use to guide their approach to security. In contrast, shift-left security is a specific strategy.

Shifting security left is a great way to help operationalize DevSecOps, but embracing shift-left security doesn’t mean you become a DevSecOps organization. DevSecOps requires additional practices, such as maintaining active communication channels between security teams and development teams, and ensuring that developers have adequate training to understand the security issues facing modern apps.

Shift-left security in practice: Two examples

To drive home what shift-left security looks like in practice, let’s consider two examples of how shift-left security can help teams avoid risky situations in the real world.

Detecting vulnerabilities in container images

First, consider a scenario where your team deploys a container image that is based on Ubuntu. The container is built using a Dockerfile that looks like this:

FROM ubuntu:20.04

RUN apt-get update && \

apt-get install -y python3 && \

apt-get clean

CMD ["some-app"]

Like all operating systems, Ubuntu is subject to a variety of known vulnerabilities, which it discloses on its website. The traditional, non-shift-left approach to detecting those vulnerabilities would be to deploy the container into production, then scan the production environment to determine whether any vulnerable software is running.

However, under a shift-left strategy, you could deploy tools that would scan the Dockerfile before the container image is built. The tools would detect that the Dockerfile uses Ubuntu 20.04 as a base image. They would then determine whether Ubuntu 20.04 is subject to any known vulnerabilities that remain unpatched. If it is, you could address the threats by using a different base image, or manually disabling or updating the vulnerable components within your container by adding commands to the Dockerfile to make those changes.

Addressing weak access controls

As a second example of shift-left security, imagine that your team plans to deploy a Kubernetes pod that is defined as follows:

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: my-app

spec:

template:

spec:

containers:

- image: my-image

name: my-app

...

securityContext:

allowPrivilegeEscalation: false

runAsUser: 0

The final line of that file – runAsUser: 0 – tells the pod to run as a user with a UID of 0. If you know much about Linux UIDs, you’ll know that UID 0 is for the root user. So, this pod would run as root, which is risky from a security perspective because some vulnerabilities are easier to exploit (or escalate into larger attacks) when the processes inside a container have root privileges.

If you take a shift-left approach to security, you could scan your pod deployment file prior to running it in order to catch the issue quickly, then fix it simply by changing the runAsUser configuration. But if you don’t scan your deployment early in the development lifecycle, you probably wouldn’t know that you are running a container as root until it is already in production. Plus, detecting the issue at that point would be a lot harder, because there is no easy way of determining the UID used inside a container from the outside.

How to shift security left

Shift-left security is a strategy, not a specific tool or practice. It can be implemented in a variety of ways.

In general, however, putting shift-left security into practice means deploying security tools that can test and validate the security of code as it flows through the application delivery pipeline. Examples of key categories of tools include:

• Software Composition Analysis (SCA): SCA tools discover vulnerabilities in source code, such as insecure open source dependencies.
• Static Application Security Testing (SAST): SAST tools can also identify some risks in source code, like lack of input validation.
• Dynamic Application Security Testing (DAST): Dynamic tests are useful for discovering security risks after applications have been compiled and are running in a testing environment.

These tools can be deployed independently. But the simpler approach is to leverage an SDLC security automation platform that automatically protects applications at each stage of the lifecycle, ensuring that DevOps teams can detect as many risks as possible, as early as possible.

Early detection is key

Shifting security left won’t automatically protect organizations against the many cybersecurity threats and risks that they face today. But it will make those threats and risks easier to detect before they become vectors for attacks against production workloads. Plus, early detection also leads to faster, simpler mitigation of security problems. It’s a win-win-win for developers, security teams and the business alike.