• The dawn of shift left
  • Shift left testing
  • The benefits of shifting testing left
  • Shift left and DevOps
• Shift left security
  • What does shift left security look like?
    • CI/CD
    • Developer environments
  • The impact of timing
  • What’s required for shift left security?
• Shift right security
  • What does it mean to shift right?
  • Is shift right really a shift?
  • Why assess security in production?
    • The definition of secure changes daily
    • Not everyone has implemented DevOps
    • Separation of duties
  • What does shift right security look like?
  • Benefits of shift right security
  • What’s required for shift right security?
• Should you shift left or right?
• Your security software shouldn’t lock you left or right
• Mondoo has you covered
  • Mondoo on the left
  • Mondoo on the right

The dawn of shift left

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.

Shift left testing

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 benefits of shifting left

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:

• It’s easier to find many types of problems before you merge code into the main development branch. The breadth of code increases after the merge, and so does the effort required to find bugs.
• It’s easier to fix problems identified when code is still being written or reviewed because the code units are small and more manageable.
• Product quality improves because you find more bugs before release.
• Time to market is quicker because the QA process shortens.

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 and DevOps

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.

‍

Shift left security

DevOps thought leaders soon applied the shift left practice to security and compliance. After all, security assessment shares many similarities with quality assurance, including:

• They’re often performed on a staged or deployed system.
• They prevent expensive incidents that can damage customer relationships.
• Some people believe they delay time to market.
• They’re often a point of friction with developers.

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 shift left security look like?

What does it mean to incorporate security into the DevOps lifecycle?

CI/CD

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:

• Traditional security vendors were quick to put this new idea into action. Their approach was to take the audits that they’d been doing in production and somehow connect them to CI/CD systems.
• At the same time, some CI/CD vendors saw the opportunity and started to connect vanilla testing tools into their CI/CD solutions in order to provide security insights.

Developer environments

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.

The impact of timing

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.

What's required for shift left security?

To successfully shift security left requires these basics:

• Source control—A code repository (with Git as a baseline) provides essential version control and collaboration tools.
• A CI/CD pipeline—You need an automated pipeline into which you can integrate security testing.
• The right security platform—Not all security and compliance software can shift left.
• Motivated team members on the left—Shift left places some security responsibility in the hands of developers and operations engineers, people who previously might not have had security on their minds.

Not every organization has these elements, so shifting security left doesn’t make sense for them.

Shift right security

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.

What does it mean to shift right?

Shift right refers to performing security testing only on built systems. For most teams, this means evaluating security in production.

Is shift right really a shift?

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.

Why assess security in production?

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:

• Constantly changing vulnerability landscape
• No DevOps environment
• Separation of duties

Let’s explore each of these.

The definition of secure changes daily

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.

Not everyone has implemented DevOps

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:

1. Developers create code.
2. A simple integration pipeline compiles and combines all of the code.
3. Operations makes the result available in a staging environment for testing.
4. After enough repetition of steps 1, 2, and 3 occured that the code on the staging environment is approved, Operations pushes the code to the production environment.

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.

Separation of duties

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.

What does shift right security look like?

Shift right security mainly consists of these practices:

• Scanning production systems for misconfigurations and known vulnerabilities
• Scanning staging systems for misconfigurations and known vulnerabilities
• Performing penetration testing on production systems

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.

Benefits of shift right security

The many praises for shift right security include:

• There’s a clear division of responsibilities.
• The Security team can concentrate on production systems.
• Developers can focus all of their efforts on innovation and building.
• Security experts have the visibility and control to be confident they’re protecting the infrastructure.
• Even older production systems get scanned for the most recently discovered vulnerabilities.
• It doesn’t rely on DevOps.

What's required for shift right security?

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.

Should you shift left or right?

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:

• The age of your project—Are you beginning a new project or updating and maintaining a legacy system? Shift left is more difficult to implement when you already have a working process in place. Conversely, when you are just getting started on a project, you can prioritize integrated security testing as you define your process and environment.
• Your development and release process—Shift left security isn’t well-suited for teams who follow a traditional code-stage-launch methodology. DevOps practitioners, on the other hand, find that shift left fits well in their lifecycle.
• Your team size and skill set—Larger teams with skills that span coding and operations are more likely to successfully assess security throughout the development lifecycle (left). Having dedicated security professionals in your organization is beneficial to all security testing, but to shift right in particular.
• Your organization’s culture—If your organization has firm restrictions concerning access to security information, it’s harder to shift security left. Most of us, however, work in environments free of such limitations.

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:

• For a new or young project with a DevOps team, start by building security testing into your CI/CD pipeline. It’s where you get the most bang for your buck. As the project nears release or matures, add continuous scanning on production systems. Ideally, one or more security specialists own production monitoring.
• If you're working on an older project or maintaining existing technology, first focus on testing production systems. Then you can steadily add ways to discover critical issues earlier in the cycle. It doesn’t have to be a full DevOps security overhaul. You simply can scan container pipelines, for example, or you can integrate vulnerability evaluations of your golden images.

Your team is unique. Make a plan that fits your own needs and capabilities.

Your security software shouldn't lock you left or right

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 has you covered

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 on the left

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:

• Hosts and container images
• Container registries
• GitHub organizations and repositories
• Machine image builds with HashiCorp Packer
• Terraform
• Kubernetes manifests

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 on the right

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.

‍