A darling of conference talks, videos, and articles, shift left security has generated some excitement in the IT community. Industry analysts claim that shift left is the future. Evangelists tell you that this change can save resources and better protect your infrastructure. And what about shift right? The shift right movement might not have as much traction, but opponents of shift left are speaking out and making their case. What do these terms really mean? What drives the strong opinions about each? And should your infrastructure security shift left, shift right, or stay right where it is?
Like every good origin story, this one begins in another land and time. To understand the history of shift left security, we look to a different business function at the turn of the millennium: software quality assurance.
In a 2001 article on DrDobbs.com, Larry Smith coined the term shift left testing. He described it as “a better way of integrating the quality assurance (QA) and development parts of a software project.” By shift left, Smith was referring to the sequential model of the software development process, which was traditionally represented by a left-to-right process diagram. Planning, designing, and building were at the left of the diagram, while testing, staging, and production were on the right.
Smith described involving QA engineers and focusing more on quality earlier in the development process—to the left.
Problems uncovered by testing late in the development process caused costly redesigns and delays, Smith explained. Considering quality and testing at all stages of the process saved both time and cost.
The shift left movement caught the attention of an industry that was growing, changing, and becoming more competitive. These benefits made shift-left testing a popular trend:
In many organizations, management loved the promise of cost savings and competitive advantage, and so encouraged their development organizations to shift testing left. Elsewhere, shift left testing was more of a grassroots phenomenon.
Shift left quickly took hold in the budding DevOps community, which was open to ideas for improving the system development lifecycle.
Industry-wide, we illustrate the DevOps cycle as an infinite loop, so the term shift left feels a little awkward.
Let’s straighten out the loop so we can see DevOps as a linear process, just for this context.
To shift testing left in the DevOps cycle means incorporating quality not just in the specified test period and in production, but also in system planning, coding, and building. Most commonly, DevOps practitioners shift left by incorporating automated testing in their development process. Testing becomes a part of their continuous integration and continuous delivery (CI/CD) pipelines.
DevOps thought leaders soon applied the shift left practice to security and compliance. After all, security assessment shares many similarities with quality assurance, including:
Have you noticed that security isn’t in the DevOps infinite loop? That demonstrates just how separate security is from traditional DevOps practice. It’s not a part of the process.
In most organizations, once a system is rolled out to production, an independent IT Security team performs security compliance audits. In contrast, champions of shift left security support incorporating security assessment into the DevOps process.
What does it mean to incorporate security into the DevOps lifecycle?
The most common approach is automated assessment of security in the CI/CD flow.
WIth CI/CD, automated testing runs on every change in the pipeline. Shift left security thought leaders had the idea to add security and compliance measures to that automation. Instead of waiting until production to find out whether systems have security vulnerabilities and misconfigurations, teams could discover them along the way. That way they’re not in a race to find security gaps in production before hackers do.
How could pioneering teams shift left? A couple of existing vendors were in good positions to provide early tools:
Farther left in the development process, you reach developers themselves. To really flex their shift left muscles, each team member could assess security while they’re still coding in their own environment. For example, an integrated development environment (IDE) could alert them when they’re pulling out-of-date dependencies into their source code. Or they can run a local security tool on their workstations.
Early security testing saves time and money. The cost of fixing bugs increases exponentially the closer you move towards production. The longer you wait to address security issues, the greater the risk to the business.
Why is that?
Traditionally, security auditors get involved very late in the development lifecycle. It’s usually either after or just before the release to production. They review systems and provide the DevOps team a list of security issues to fix. There’s a fundamental challenge to making changes this late in the process. The Security team is asking developers to alter the environments that their systems depend on—changes that could break everything.
For example, a common instruction that arises from a security audit is to update a source code dependency package version. Some new packages have breaking changes. Other packages are claimed to be free of breaking changes, but actually do have them. When developers update a package, they usually have to rewrite and retest code.
There are known and unknown risks in every change on the auditor’s list. In a security audit run just before release, the changes require rework.
A production audit can push developers to make changes to software that customers are already using. These changes run the risk of introducing bugs or breaking changes to working systems.
Similarly, it’s more efficient for operations engineers to learn about security issues in new infrastructure before deployment. It saves them rework. Today, modern DevOps teams rely heavily on container orchestration and infrastructure tools like Kubernetes and Terraform. Traditional audits ask them to make configuration changes after they’ve already deployed. It’s far more efficient to identify changes before deployment and rely on security-checked manifests and configuration files.
To successfully shift security left requires these basics:
Not every organization has these elements, so shifting security left doesn’t make sense for them.
A few voices have responded to the loud chorus of shift left advocacy. They point out that one solution isn’t right for every team, and warn not to neglect testing security on the right. Whether they call it shift right, guard right, or extend right, what they’re all saying is that there is value in testing security at the end of the systems development lifecycle.
Shift right refers to performing security testing only on built systems. For most teams, this means evaluating security in production.
Right now, are you thinking that this description of shift right sounds an awful lot like the traditional method of ensuring systems are secure? You’re not wrong! The expression shift right really is just a response to shift left. Call it guard right, extend right, or whatever works for you.
With so many benefits of shifting security left, why isn’t everyone doing it? There isn’t one single answer, but for most teams, one or more of these factors influence the decision:
Let’s explore each of these.
A major motivator for shift right security is the rapid growth in known vulnerabilities in the software and packages on which all IT teams rely. The National Institute of Standards and Technology (NIST) announces new common vulnerabilities and exposures (CVEs) every day. DevOps can perform thorough security testing in the development process and release an airtight product, but within hours of releasing to production, new CVEs can reveal that the product is vulnerable.
Teams who only assess security in the development environment and CI/CD have no idea what vulnerabilities exist in production. Regularly (or continuously) evaluating the security of a production environment is the only way to ensure that systems are fortified against the most recently discovered security risks.
DevOps is still a young practice. While software companies and other high-tech organizations commonly embrace DevOps, millions of IT teams (typically within organizations that don’t sell technology) do not. Most of them follow a traditional code-stage-launch workflow:
Typically this process lacks the automation that DevOps relies on. There is no CI or CD and there is seldom built-in testing. There is little opportunity for shift left security in this process.
Many shift right security advocates believe that security should always be separate from development and operations. They believe it’s important to have security experts dedicated entirely to finding gaps in infrastructure while developers and operations focus on planning, innovating, building, maintaining, and improving.
In some organizations, this separation is a requirement, not a preference. Some financial and government institutions need security efforts to be completely separate from the rest of the organization’s operations. Shift right security is easier to fit into this type of environment.
With shift left, DevOps team members see the system’s vulnerabilities. That’s unacceptable in some highly restrictive environments. Their guideline is that only the Security team should be able to see the exposed risks. Their role is to find them, identify what needs to change, and communicate the required changes to DevOps.
Shift right security fits this strict separation of duties. The Security team audits the system and identifies vulnerabilities. They prioritize the vulnerabilities (which ones are most important to fix now) and research how to fix them (for example, patches to apply) and let the DevOps team know. The DevOps team implements the changes without ever learning what vulnerabilities existed and/or still exist.
Shift right security mainly consists of these practices:
As Security teams learn about new vulnerabilities in software, they can scan for those issues immediately in production. Penetration testing can focus on more complex means of gaining access to infrastructure.
The many praises for shift right security include:
All you need to implement shift right security is a tool for finding vulnerabilities in your production systems. That’s basic shift right testing. You can use the same tool to expose security risks in a staging environment as well. Add in-house or consulting penetration testers, and you have shift right security covered.
Here’s the big question: Which is best for you, shift left or shift right security? Ideally, both: You should test throughout development and also in production. If you practice DevOps, then it’s been shown again and again that testing security in the coding environment and the automated pipeline reduce work, speed time to market, and release with fewer initial misconfigurations and vulnerabilities. And it’s also important to continuously scan your production systems to stay up to date with constantly growing known risks.
But, of course, not everyone can match the ideal. So let’s ask again: Which is best for YOU? The answer depends on:
Don’t think of security as either left or right. See your infrastructure’s entire lifecycle as multiple opportunities to safeguard from attackers. The more testing you do, the more you can protect your organization. If end-to-end security is too much to take on at once, start small and grow. For example:
Your team is unique. Make a plan that fits your own needs and capabilities.
Your projects, organization, and team will all grow and change. Your security software should be able to meet all of your needs, spanning left and right. Don’t let your software dictate how you safeguard your infrastructure.
Mondoo doesn’t limit you to shift left or shift right; it allows you to assess security both in the development lifecycle and in production.
Mondoo integrates smoothly with your existing pipelines to deliver insights throughout the DevOps lifecycle. For developers and operations engineers to adopt shift left without resistance, they need software that integrates security scans into their existing workflows.
For example, with Mondoo’s full-stack security platform, your team can keep using the tools they already love. Mondoo continuously checks for vulnerabilities and misconfigurations in your existing pipelines, including GitHub Actions, GitLab, CircleCI, Azure Pipelines, Jenkins, and more.
Mondoo’s shift left reaches farther than other shift left security platforms: It finds vulnerabilities and misconfigurations on developers’ machines, before their code even enters the pipeline. This can prevent security issues from slowing anyone down.
Mondoo lets you smoothly add security analysis to the tools and artifacts that already work for you:
With such ease of integration, Mondoo becomes an essential part of your development lifecycle without adding friction or burden. Shift left is elegant with Mondoo.
Mondoo continuously searches for misconfigurations and vulnerabilities in production environments.
Choose from over 100 out-of-the-box security policies certified by Mondoo and CIS, and customize them based on your organization’s unique needs.
As new vulnerabilities are announced, Mondoo updates the policies you’re using to find those gaps. That means your production systems, no matter how long they’ve been deployed, are always held to the latest security standards—with no work required of you.
Beyond detection, Mondoo provides instructions for fixing the security issues it finds in your infrastructure. You don’t need to research what patch fixes a CVE that Mondoo finds; Mondoo already has that information for you. You don’t need to read documentation to learn how to change a critical configuration setting; it’s right in the Mondoo UI for you to copy.
Mondoo does more than just identify security issues; it sends you on a fast track to remediation.
Mondoo combines smoothly integrated testing in your pipeline and coding environments with flexible and thorough production monitoring. Safeguard your business-critical systems with the single platform that covers the full security spectrum.