Software composition analysis (SCA) technology helps software providers create and maintain secure codebases by analyzing code, detecting cybersecurity vulnerabilities and risks, and directing developers to the appropriate solutions to those issues.
As cyber crime continues to increase in frequency and magnitude, companies turn to SCA solutions to not only reduce their exposure to vulnerabilities but also reduce the time and effort spent in addressing them. Recent trends in both cyber crime and cyber legislation have driven companies to seek solutions that scale with today’s security issues, and SCA is becoming a staple in any smart technology company’s cybersecurity toolkit.
MergeBase is at the forefront of innovation in the SCA space, and we’ve created this primer on SCA to help you and your team understand what software composition analysis is, what it’s used for, and why it’s so important in today’s global tech environment.
In short, software composition analysis is a category of tools that detect vulnerabilities within the components of your software offerings. This protects you from inheriting vulnerabilities from the open source libraries you’ve built your product on.
Cyber crime is on the rise: damages from breaches are on track to reach $4 trillion USD in 2022. Right now, cyber crime is the third-largest source of global criminal damages, after drugs and corruption. By 2028, cyber crime will be number one.
As cyber crime grows, hackers find new ways to exploit you (and everyone else). One way that cyber criminals do this is by finding vulnerabilities in open-source libraries that developers rely on. This gives them access to not only the core libraries but also the software that other people have built on top of the exploited open source code.
Smart developers respond by using SCA tools like MergeBase to constantly analyze their code, scanning for any new vulnerabilities.
The types of tools that we consider SCA might go by other terms. This can lead to a bit of confusion when you’re looking for a security solution. Terms such as “open source security” and “software supply chain security” when voicing needs and recommending solutions—but all three live in the same conceptual neighborhood, and these terms overlap a great deal.
“Open source security” is more widely used outside the field of development security. Most nontechnical managers have a good idea of what open source is, and so the term has caught on in the general business community.
Meanwhile, “software supply chain security” has become the favored term by nontechnical folks in regulatory environments (e.g., politicians, legislators, and nontechnical risk managers). Software supply chain security is a bit broader than SCA, because, in addition to the issue of transitive vulnerabilities, it covers additional activities such as:
If you’re being told to look into open source security and/or software supply chain security, it’s likely that an SCA solution will fit the bill—or at least part of it.
The SCA process can be described in three steps:
By doing this, SCA tools help you build and ship code with confidence.
Discussing vulnerabilities can feel a bit abstract, and it can be a confusing topic to discuss with people unfamiliar with cybersecurity.
So we’ve found this analogy helpful.
Imagine you’re making cookies for someone with celiac disease. Gluten is toxic to this person, so you need to ensure none of it makes its way into the final batch. Making a gluten-free meal is, in many ways, similar to providing vulnerability-free software.No home recipe is going to call for “a half-cup of gluten.” Instead, you need to analyze the ingredients the recipe calls for in order to see if they have gluten in them.
This is very similar to the problem software providers face when it comes to security. SCA detects obvious, surface-level vulnerabilities, but it also finds fixes and patches to the open source libraries that you’ve built your product on. This keeps your product free of any known vulnerabilities.
SCA and gluten-free cooking: an analogy
|In gluten-free cooking …||Likewise, in software security …|
|Scanning components||Let’s say your recipe calls for all-purpose flour. While “gluten” is not listed as an ingredient, you know that flour contains gluten. A gluten-conscientious cookbook will tell you what to use as a substitute, or point you to a new recipe altogether.||An SCA solution will scan every “ingredient” of your software to detect vulnerabilities. SCA solutions like MergeBase alert you of these problems and provide patches and updates to fix them.|
|Scanning external references||Sometimes a recipe references other recipes (e.g., a recipe for cookies may recommend using an icing recipe elsewhere in the cookbook). As the chef, you need to make sure these complementary recipes don’t contain glutenous ingredients, too.||An SCA tool will check any libraries your software references and alert you if those libraries expose you to any vulnerabilities.|
|Scanning subcomponents||Sometimes your ingredients have ingredients (e.g., your cookie recipe may call for a package of Hershey’s “Whoppers”). You now need to check the ingredients panel of that package to make sure there’s nothing glutenous in that ingredient, too.||SCA not only scans the libraries you’ve built your tools upon, but the libraries those libraries are built upon, giving you a full view of your software supply chain.|
|Scanning your environment||If you don’t wash your mixer, bowl, and pan after making glutinous food in them, they contaminate your otherwise gluten-free dish. Not only does your recipe need to be gluten-free, but your cooking environment (surfaces, pans, utensils, etc.) need to be gluten-free as well.||A comprehensive SCA solution also scans your development environment, keeping you clear of vulnerabilities while you’re building your software.|
|Scanning the final product||You’ve finished your batch of cookies, but you want to be absolutely sure they’re safe. You might use a gluten sensor on the final dish, for peace of mind.||SCA solutions scan the final built artifact before (and sometimes after) deployment for vulnerabilities.|
NOTE: MergeBase checks your live software continuously (using Run-time Application Security Protection, or “RASP”), and we are the only major SCA provider that does so.
It’s an imperfect analogy (most analogies are), but it can help nontechnical stakeholders understand what SCA is, why it’s valuable, and what to expect from a comprehensive solution.
The right SCA solution will bring your organization three main benefits. You will avoid transitive vulnerabilities as described above, and you’ll also avoid legal risks and unnecessary security costs.
While SCA’s primary function today is to catch security vulnerabilities, the technology was originally developed to protect against a different kind of threat entirely: the threat of being sued for breaching license agreements.
Building solutions atop open-source libraries comes with some risks surrounding license litigation. In the past, developers (and organizations representing open-source contributors) have sued large companies for using open-source code in commercial products. (The organizations claimed that these companies had violated the GNU General Public License Version 2 (“GPL”), a license that the development community generally considers toxic today.) Furthermore, it is not unheard of for rogue developers to threaten companies with legal action for personal gain, claiming that the target companies are in violation of license agreements or copyright law.
While this sort of activity is rarer these days, a good SCA solution will alert you of any material in your code that is under the GPL license, protecting you from accidentally opening yourself up to this kind of legal action.
No discussion of SCA would be complete without considering the financial threat of false positives.
Developer time is expensive. The longer it takes to detect and fix breaches, the more expensive your security becomes. And if your developers are hunting down a vulnerability that doesn’t exist, it will take even longer (and cost even more).
A good SCA solution not only makes it easy for your developers to quickly locate and fix problems, but it also won’t alert you to vulnerabilities that don’t exist. This reduces the opportunity costs associated with fixing issues, and allows you to better allocate development resources.
(Incidentally, MergeBase has an exceptionally low false positive rate—it’s a primary reason our clients choose us over our competitors.)
SCA is recommended for anyone who makes software. Users expect the software they pay for to be secure, even as rising cyber crime makes it increasingly difficult to provide that security.
But beyond software providers, SCA is useful for anyone using software in their business process, especially large companies. Even if you’re using ubiquitous tools and platforms like JIRA or SAP, it’s wise to have a handle on any potential vulnerabilities that may work their way into those systems, especially if you are running them on-premise. This is an important part of keeping your own company’s information secret and secure.
SCA is becoming increasingly popular. In 2019, only five percent of companies used SCA—by 2024, sixty percent of companies will be using it. Just like firewalls became the norm decades ago, SCA will soon become a staple in cybersecurity.
SCA is the future of software security, and MergeBase is leading the charge in creating efficient, effective tools for businesses of all sizes.
We’ve built MergeBase to provide comprehensive coverage of the software supply chain, covering the full lifecycle of software development. MergeBase performs everything we’ve described in this piece: detecting vulnerabilities (even those within subcomponents of subcomponents), identifying legal issues, and reducing overall security costs.
Development resources are already spread thin, so MergeBase is built to keep your software secure and lighten the load for your security team. Because of our low false positive rate, technology teams trust MergeBase to surface issues in ways that make it easy to prioritize security efforts.
Beyond this, MergeBase extends into the deployment and runtime phases of software development. For some issues, MergeBase even allows nontechnical staff to apply solutions with a few simple clicks—further reducing the time it takes to find and fix security problems in your product.
If you are considering SCA options, we would love to show you how MergeBase can keep your security team running and your software secure. Start a free trial and explore our solutions, or contact us to book a private demo today!
Background Why do we need a Software Composition Analysis tool against open source software vulnerabilities? Well, that is a long story: Commercial and industrial software is now primarily constructed from components. Open source components, to be exact. Open source software licenses dramatically decrease business frictions that arise from incorporating and integrating software developed by external entities. No […]
We recently (August 2020) completed version 1 of our .NET scanner. Its goal is scanning .NET and NuGet projects for libraries with known vulnerabilities in any .NET project. For this blog post, we thought we’d take our scanner out for a spin and see how it compares against the competition. TL;DR: Here are the results […]
Introduction Über jars are a type of reuseable Java library that applications sometimes (knowingly or not) incorporate into their systems. Über jars are particularly challenging for software composition analysis (SCA) tools to understand because their structure and organization are complex. In this blog post, I explain what über jars are and why they exist, and […]
Software development based on the sharing and collaborative improvement of software source code goes back to its origins. In the late 1990s, the term “open-source” was coined and received mainstream recognition in publications such as Forbes. The Netscape browser’s source code was made open source, which got a lot of attention.
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.