Shift Left Security: Protect Your Dev Life Cycle with Software Composition Analysis

If you’re a developer (or work closely with developers), you’re likely already familiar with the concept of Shift Left Testing. This is the practice of testing your code earlier in the dev cycle rather than later.

Traditionally, software goes through the plan, code, and build phases before being tested. However, more and more organizations have recognized that holding quality assurance until the end of the process often leads to a lot of recoding and rebuilding—which takes up time and energy that could be put to more valuable use.

(The concepts of “left” and “right” in this discussion refer to a timeline: the earlier something takes place, the further “left” it shifts on that timeline.)

Shift Left Security refers to the practice of addressing vulnerabilities earlier in the development process. It’s a sub-practice of Shift Left Testing. Rather than testing code for vulnerabilities right before pushing it live, DevOps teams that shift their security left keep their code vulnerability-free as it’s being built. 

In this article:

Shift Left philosophy explained (a nontechnical analogy)

“Shift Left” may sound like in-speak to people outside the development world, but the philosophy of catching mistakes early is intuitive. In fact, anyone who has had to turn in a written homework assignment has benefitted from Shift Left thinking.

Imagine you’re turning in a final paper for a class. A portion of your grade will be determined by your use of grammar, spelling, and punctuation—and you lose points for every mistake.

If you approached this assignment using traditional Shift Right practices, you’d write the paper, then review the text for errors. This could be a big task, and even if you’re using a spelling and grammar check tool, you’ll likely need to re-read old paragraphs to make sure the suggested edits align with what you were trying to communicate.

However, most word processors today help you catch errors as soon as you make them. Red underlines tell you you’ve written a word that isn’t in the dictionary. Blue underlines tell you where you’ve mistakenly used “effect” instead of “affect.” And common typos like “teh” and “adn” are automatically corrected to “the” and “and.” 

These word processors have “shifted left” the spelling and grammar check process. They flag and sometimes automatically fix mistakes as they happen. Not only do you finish your draft with fewer mistakes, but you also get to see what kind of mistakes you commonly make as you’re making them, ensuring you’re less likely to confuse “infer” and “imply” in the future.

Shift Left Security applies that same principle to catching vulnerabilities as early in the software development life cycle as possible.

Benefits of Shift Left Security

As you can imagine, Shift Left Security brings software companies a host of benefits.

Better use of dev time (and money) 

By reducing the amount of recoding and rebuilding work, developers can focus their time on coding and building software that’s already cleared for security. This means more dev labor goes toward what you hired them to do: development.

Faster development cycles

In tandem with the previous benefit, Shift Left Security makes it possible for software to more quickly enter the deploy phase—which enables you to innovate and compete at a faster rate than you would otherwise.

More customer trust 

By keeping software secure throughout the development life cycle, you reduce the chances of vulnerabilities entering the final product. Being able to innovate quickly and securely gives your sales team an advantage when selling to potential clients—especially when those clients are enterprise or highly regulated organizations.

Better team morale (and productivity)

Nothing kills morale like needing to start over. When you shift your security left, you reduce the number of times your team will need to do that—making their jobs less frustrating and more satisfying. 

The problem: most vulnerabilities come from outside

Shifting security left helps you catch vulnerabilities early—but not all vulnerabilities come from the same source. While a static application security testing (SAST) tool can help you catch mistakes and vulnerabilities in the code your team writes, it won’t protect you from vulnerabilities that come from external sources.

And most vulnerabilities arise from third-party code. Unless your team builds 100% of your software from scratch, your final product relies on a mix of open-source libraries and code licensed from vendors. As these libraries are updated over time, people inevitably discover vulnerabilities—and these vulnerabilities can become security hazards to you and your customers. 

These transitive vulnerabilities go through their own lifecycle, which can be described as four phases.

1. Discover

Most known vulnerabilities are found in one of three ways:

The source discovers the vulnerability themselves. One of your vendors might discover a vulnerability in their code via a routine security check, or during the process of making other updates.

White-hat researchers discover a vulnerability. Teams of “good hackers” regularly study other organizations’ systems in order to find weaknesses in their software. When they find a new vulnerability, they’ll usually alert the vulnerable library’s author. Instead of exploiting the weakness, their end game is to help find and patch them before …

Black-hat researchers discover a vulnerability. These folks find and exploit vulnerabilities for their own agendas—usually to ransom companies for money, steal data, or cause mayhem. 

2. Report

Once a library’s author knows about a vulnerability, they’ll usually make an announcement so that people relying on the vulnerable code can take protective measures. 

Some white-hat researchers will also take it upon themselves to alert people about known vulnerabilities. (Google’s Project Zero is an example of white-hat researchers who publish their findings.)  

3. Fix

Once they’ve shared the vulnerability with people who need to know, the author of the vulnerable library gets to work on fixing the problem. When they’ve made a patch, the author makes the secured, updated library available to their partners and customers.  

4. Implement

Fixing the problem within the source library doesn’t always automatically patch the vulnerability for everyone who was using the vulnerable code. Once the fix is available, everyone using the broken code still needs to implement it.

Sometimes this is as simple as updating from one version to the next, e.g., updating from App 2.3.1 to App 2.3.2. But other times, the fix is contingent upon other libraries and systems being in place—sometimes, implementing one fix can involve updating (or even upgrading) multiple other libraries.

Fortunately, it’s not necessary to manually keep track of new vulnerabilities and fixes—you can use software tools to do much of this work for you. 

Using software composition analysis (SCA) to shift security left

Software composition analysis (SCA) tools scan your third-party code for known vulnerabilities. Depending on the solution you use, SCA can also direct you to appropriate fixes—and sometimes, it can even implement those fixes automatically.

SCA is still an emerging product category, and software companies can choose to use free or paid options. Both can help you shift security left, but paid options (including ours) have far more to offer when it comes to securing your development process.

Free SCA tools

Free SCA tools give you some ability to scan for third-party vulnerabilities in your build and testing environments. The benefit of using these is that they are, well, free. However, the two leading free SCA tools (NOM Audit and OWASP Dependency Check) come with a few significant drawbacks. 

First, free SCA tools draw from limited sources. In order for an SCA tool to scan for vulnerabilities, it must have a source of vulnerabilities to reference—a list of canonical vulnerabilities to look for, if you will. The more sources an SCA tool draws from, the more comprehensive its vulnerability checks will be. 

Both of the leading free SCA tools draw from smaller, more limited pools of known vulnerabilities, which means they cannot give you comprehensive coverage. (For example, OWASP Dependency Check solely references the National Vulnerability Database.)

Second, free SCA tools are notorious for false positives. Free SCA tools have a tendency to cry wolf, raising alarms for vulnerabilities that aren’t actually there. While it’s good to be vigilant about your application’s security, one of the reasons for shifting left in the first place is to make better use of your developers’ time. Sending developers down wild goose chases only to find false positives cuts into the time you would have otherwise saved.  

While free SCA tools are better than nothing, the lack of development team power behind them means they have a hard time keeping up with paid options. 

Paid SCA tools

Paid SCA tools (like MergeBase) allow you to shift left in far more powerful ways. A good paid solution will have several features and capabilities that free solutions simply can’t support today:

• Multiple vulnerability sources. Paid tools reference multiple sources when scanning for vulnerabilities, so they have a wider range of issues to check for. 
• In-house research teams. Paid SCAs often employ teams of researchers to manually check up on the accuracy of the tool’s reports, verifying hits and minimizing misses. 
• Vastly improved accuracy. By combining the previous two capabilities, these tools tend to flag more vulnerabilities with fewer false positives.
• Patch recommendations and (sometimes) autofixes. Paid tools provide sophisticated recommendations when it comes to addressing the vulnerabilities they find—and a few of them (MergeBase included) can even automatically fix some issues for you.

Most paid SCA tools will help you shift security left in substantial ways. However, they also strictly focus on the build and test environments—they aren’t typically strong at scanning your production environment. 

MergeBase is the exception to this rule. Like other paid solutions, we scan your software in build and test environments. But we also analyze your live product for any vulnerabilities that emerge (and for many of these vulnerabilities, MergeBase automatically implements fixes for you).

Shift security left with MergeBase 

Shift Left practices are common sense, but they’re not always easy to implement. At MergeBase, we’ve created an SCA platform that does the heavy lifting for you, so you can keep your code secure while you’re building it.

If you’d like to see how we can help you shift security left, schedule a MergeBase demo today!