Individuals and businesses depend on software daily – for work processes, shopping, booking travel, banking, entertainment, etc. That much may be obvious. But what you may not know is that much of that software is open source. In other words, components built by volunteers that make up freely accessible code used to create that software we all depend upon.
What is the open source software landscape?
The Open Source Security & Risk Analysis (OSSRA) research report, now in its eighth iteration, is dedicated to “helping security, legal, risk, and development teams better understand the open source security and license risk landscape.” While open source code is freely accessible to use, that doesn’t mean it’s free of certain rules of engagement.
Users must comply with licensing obligations. While the percentage of licensing conflicts in the codebases analysed in the 2023 OSSRA report decreased from 65% to 54% from 2020 — 2022, that improvement still means that over half contained violations of license terms. And this could lead to very real legal liability or proprietary code in an app to be made public.
That said, open source is essentially “the foundation for every application we rely on today,” as the OSSRA report puts it. Open source is overwhelmingly popular, and for good reason. Not only is it free of cost, but it can also be modified to meet the needs of its users.
Therefore, open source eliminates the need to reinvent basic software building blocks. The key is finding new and innovative combinations of those existing building blocks that empower software development to be faster, less expensive, and more efficient.
Why you businesses should tread lightly
At the same time, we mustn’t ignore the potential risks open source poses. While no more or less vulnerable than any other type of software, vulnerabilities in the open source supply chain cannot be managed in the same way as software organisations create in-house or purchase from a commercial vendor. And there are several reasons why:
Open source patches aren’t ‘pushed,’ but rather, ‘pulled’
Put another way, you may see update notifications on your mobile device. These updates are ‘pushed’ to your phone. Open source updates, on the other hand, must be sought out.
Considering that you can’t maintain what you don’t know you’re using, if an organisation doesn’t know it’s using a vulnerable component, it won’t be able to apply a patch, even if one is available. Interestingly, this year’s OSSRA reports that 91% of the codebases examined included outdated (i.e., unpatched) versions of open source components.
Not all open source projects are treated equally
Many popular open source projects are made up of hundreds of volunteers helping to maintain the code. Conversely, millions of less popular projects have fewer than 10 people maintaining them. Some have even been abandoned completely. The 2023 OSSRA reports that 91% of the codebases analysed included components with no development for two years. Additionally, 89% included components that were over four years out of date.
Developers aren’t necessarily security experts
Developers often don’t vet open source components before incorporating them into codebases. 2023 OSSRA data found open source in 96% of the codebases analysed, and it made up the majority — an average of 76% of the components comprising the codebases.
For added context, the average number of open source components in a codebase was 595, up 13% from 528 the previous year. This means that virtually every firm relies on a highly complex open source software supply chain. As the open source landscape grows, there are also some promising ways to approach securing the open source supply chain.
The 2023 OSSRA reports that there is increased interest in open source risk management. According to the research, 73% of organisations surveyed reported that they had “significantly increased their efforts to secure open source software, container images, and third party software components as a result of recent software supply chain attacks.”
Thankfully automated tooling solutions can help! Software composition analysis (SCA) identify components in your software supply chain and inform you of known vulnerabilities.
SCA tooling will also help to create a software Bill of Materials (SBOM), a detailed inventory of every component in a codebase, including information on each of those components: Who made it, when, who is maintaining it (or not), what version you’re using, if it has any licensing restrictions, and if it has any known vulnerabilities. That includes tracking whether a given component relies on other software components, called dependencies, to function correctly.
As the recent OSSRA report puts it, “the concept of a software Bill of Materials (SBOM) derives from manufacturing, where the classic Bill of Materials is an inventory detailing all the items included in a product. When a defective part is discovered, the manufacturer knows which of its products is affected and can begin the process of repair or replacement.”
While an SBOM is essential, and automated, that doesn’t mean that it will do all the work for you. An SBOM will inform you of what’s in your software, which will help you know if there is a vulnerable component that needs to be patched; however, it won’t tell you how to patch it or if it has been patched. That part will still require some human intervention…for now.
Phillip Ivancic is the Head of Solutions Strategy for APAC at Synopsys.
