DEVOPSdigest

Every individual and every organization depends on software — for work, shopping, banking, travel, entertainment, communication, household appliances — the list goes on. What users may not know is that most of that software is open source: components built by volunteers that make up freely accessible code that can be used to build software.

While open source code is freely accessible to use, it's not free of obligation. Users must comply with licensing provisions. The eighth edition of Synopsys' Open Source Security & Risk Analysis (OSSRA) Report analyzed more than 1,700 codebases and found a decrease in the percentage of licensing conflicts from 65% to 54% from 2020-2022. That improvement still means that more than half contained violations of license terms; those could lead to legal liability or requiring proprietary code in an application to be made public, as took place with Oracle(link is external) several years ago.

That doesn't mean organizations shouldn't use open source — it's essentially the foundation for every application we rely on today.

Open source is overwhelmingly popular for good reasons. In addition to being free of cost, it can be modified to suit the needs of users. So it eliminates the need to "reinvent the wheel" by rewriting basic software building blocks from scratch. The creativity and originality comes from finding new and innovative combinations of those existing raw materials that empower software development to be faster, less expensive, and more efficient.

That said, you can't ignore the risks.

1. Open source patches and updates aren't "pushed" to users, but have to be "pulled." If an organization doesn't know it's using a vulnerable component, it won't know it needs to apply a patch, even if one is available. And that problem is rampant. This year's OSSRA reports that 91% of the codebases examined included outdated (i.e., unpatched) versions of open source components.

2. While many popular open source projects have hundreds of volunteers helping to maintain the code, millions of less popular projects have fewer than 10 people maintaining them. Some have been abandoned altogether. The 2023 OSSRA report found that 91% of the codebases analyzed included components with no development for two years. And 89% included components that were more than four years out of date.

3. Developers often don't vet open source components before incorporating them into a codebase, inviting additional risk. The latest OSSRA data identified open source in 96% of the codebases analyzed, and it comprised the majority — an average of 76% of the components making up the codebases. Also, the average number of open source components in a codebase was 595, up 13% from 528 the previous year. This means that virtually every organization relies on a highly complex open source software supply chain.

Among promising trends is that the 2023 OSSRA report found increased interest in open source risk management. Of those analyzed, 73% of organizations said 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.

But interest hasn't always yielded results. Nearly two years after President Biden's executive order on Improving the Nation's Cybersecurity(link is external) (EO 14028), which called for improved software supply chain security, this year's OSSRA data showed that organizations are still struggling with supply chain basics — understanding the breadth of their software supply chain, establishing visibility into the software they depend on, and satisfying growing transparency pressures for the software they distribute and sell.

There are effective ways to improve the security of the open source supply chain. To help you know and track what you're using, an automated software composition analysis (SCA) tool can identify open source components in your software supply chain and tell you of known vulnerabilities in any of them. A robust SCA tool 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.

As we look to the future of open source coding it's clear that the use of open source will continue to grow at a pace never before seen. Which is why it's critical to understand the building blocks of your software so that your organization isn't infusing vulnerable code into it, and similarly, to ensure the components remain up-to-date and compliant with applicable open source licenses. If you do that, open source will help make your business, not break it.