:
Skip Navigation
Book a Demo
Book a Demo
Resources Articles Shift Left

Shift Left

Thinking about security early saves time and accelerates innovation by preventing rework and reducing technical debt.

What is Shift Left?

A central pillar of DevOps and DevSecOps is Shift Left, also called Start Left. This phrase describes the principle of testing and checking code quality early in the software development life cycle (SDLC).

As you can imagine, this puts developers on the front lines of quality, security, licensing, and operations. And success on the front lines requires tools that make it easy to select the best open source software (OSS) components.

What does Shift Left mean?

In the past, the SDLC was mostly sequential. No phase in the process would begin until the previous phase was complete. A visualization would look something like this.

image1

 

This visualization is often called the Waterfall Model due to the falling action of the steps. This model is still how lots of physical goods are manufactured.

And for physical goods, a mostly sequential process makes sense. You can't package eight ounces of macaroni noodles until the noodles are made. You can't make the noodles until the ingredients are mixed. And you can't mix the ingredients until they arrive in the warehouse, and so on.

But software isn't bound by those constraints. As Agile and DevOps methodologies became popular, organizations began to think differently. Tests and quality checks don't need to wait until developers hand off their code. Instead, they can happen as developers are developing. Visually, quality checks and testing shift left. That's the origin of the term.

The benefits of shifting left include:

  • Faster development

  • An increased capacity for innovation

  • More stable, low-maintenance deployed software

  • The elimination of rework through early communication and issue detection

  • Avoiding release delays due to unforeseen security and legal issues

  • More time for SDLC development

Why does DevOps recommend Shift Left testing principles?

You might have deduced that shifting left requires reorganizing your organization's workflows. And you'd be correct. Companies that want to shift left must comprehensively evaluate their processes and procedures.

Organizations succeed at shifting left when they make priorities of the following:

 
Automation

Manual tests and quality checks are time-consuming, frustrating, and introduce human error. Worse, it reinforces the silos between Dev and Ops — the opposite of what DevOps tries to do.

Similarly, the modern streamlined SDLC creates blind spots in quality, licensing, and security. Manual testing can only conform to the patterns of these blind spots. For these reasons, shifting left requires automation.

 
Scalability

If an organization’s capacity to test early can't scale, traditional workflows will resurface. Shifting left requires processes accommodating teams of one, ten, or a thousand developers.

 
Communication

If Security and Legal stakeholders don't make their expectations clear, then early quality checks will be useless. Stakeholders must communicate to developers in a way that's understandable and actionable.

Likewise, if feedback from early testing requires lengthy downtime, then developers will avoid testing. Feedback must be quick, visible, and easy to understand.

 
Contextualization

Not every snippet of code requires the same level of scrutiny. For example, a security vulnerability that’s dangerous for software being hosted might not matter for software being distributed. If tests and quality checks don’t adjust to the context of the code, then developers will avoid testing. Shifting left demands testing and quality checking that’s contextual.

Developers are at the center of Shift Left

Shifting left puts developers on the front lines of quality, security, licensing, and operations. But it's not about saddling developers with more responsibility. In fact, shifting left reduces the developer's workload by transforming critical late-game issues into trivial early-game fixes.

Here's an example. Developers tend to outnumber Ops and SecOps at most organizations. The ratio is usually estimated at 100:10:1. That means that, for every Security employee, there are 10 Operations employees and 100 developers. In other words, developers outnumber Security by two orders of magnitude. Under the Waterfall model, SecOps will be overwhelmed with testing, and vulnerabilities will slip undetected into the Deployment phase. When they're discovered, developers are forced to engage in excruciating rework.

But in an organization shifting left, early quality checks catch vulnerabilities at the development phase, where fixes are easier. This avoids rework, and developers and SecOps see lighter workloads throughout the SDLC.

Shifting Left means leveraging OSS components

It's not news that software development revolves around OSS components. In fact, 90% of any given application consists of OSS components. In 2020, developers requested more than 1.5 trillion OSS components and containers. These figures show that researching, selecting, and assembling OSS components dominates developers' time.

Let's put that in the context of Shift Left. Consider what we've discussed so far.

  • Shift Left is the principle of testing and checking code quality early in the SDLC

  • Developers are at the heart of the shift

  • Its essential priorities are Automation, Scalability, Communication, and Contextualization

And knowing that modern software development is about OSS components, we can summarize by saying that shifting left is about having tools for developers that…

  • Transform the expectations of security and legal stakeholders into actionable policies that are automatically enforced

  • Help developers select OSS components maintained by exceptional teams

  • Identify OSS components that are popular within the community

  • Check for security and licensing issues on OSS components as they're being selected

  • Provide quick feedback, delivered inside the tools that developers already use

  • Scalable for development teams of any size

  • Can be contextualized for the needs of the specific project

  • Show a clear and easy path for remediating violations