Welcome! We are moving the content of this guide to the guides section of Learn.Sonatype.com. You will find the most up to date information there.
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.
Defining Shift Left by Comparison
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.
This visualization is often called the Waterfall Model, since the falling action of the steps resembles a waterfall. The Waterfall Model is still how lots of physical goods are manufactured.
And for physical goods, a mostly sequential process makes sense. You can’t package 8 ounces of macaroni noodles until the noodles are made, you can’t make the noodles until the ingredients are mixed, 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 speed, stability, and an increased capacity for innovation. Shifting left eliminates excruciating rework by communicating expectations and uncovering issues early, leaving more time in the SDLC for development. It also ensures that deployed software is more stable and needs less maintenance, and releases won’t be delayed for security or legal issues.
Priorities of Shift Left
You may have intuited that shifting left will require some reconfiguring of your organization’s workflows. You’re right. Organizations that want to shift left need a holistic review of their processes and procedures.
As DevOps pros, Sonatype sees organizations succeed at shifting left when they make the following things priorities.
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 blindspots in quality, licensing, and security. Manual testing can only conform to the patterns of these blindspots. For these reasons, shifting left requires automation.
If an organization’s capacity to test early can’t scale, then traditional workflows will resurface. Shifting left requires processes that can accommodate teams of one, ten, or a thousand developers.
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.
Not every snippet of code requires the same level of scrutiny. For example, a security vulnerability that’s dangerous for software that’s being hosted might not matter for software that’s 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 that’s 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 over the whole of the SDLC.
Shifting Left Means Leveraging OSS Components
It’s not news that software development revolves around OSS components. In fact, according to Sonatype’s State of the Software Supply Chain report, about 90% of any given application consists of OSS components. Over the course of 2020, devs requested more than 1.5 trillion OSS components and containers. From these figures, you can see that researching, selecting, and assembling OSS components dominates a developer’s 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 devs 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 Devs 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
Talk to Us
And visit my.sonatype.com for all things Sonatype.