Black Duck contributes to the Linux Foundation Census II of the most widely used open source application libraries

Mar 10, 2022 / 5 min read

Table of Contents

Purpose of Census II
Challenges of open source management
Issues affecting long-term security of free and open source software

Last week, the nonprofit Linux Foundation and Harvard’s Lab for Innovation Science published Census II of Free and Open Source Software—Application Libraries. This report identifies more than 1,000 of the most widely deployed open source application libraries. Black Duck Cybersecurity Research Center (CyRC) was among the contributors of anonymized usage data based on scans of codebases at thousands of companies, providing data that allowed for a more complete picture of the free and open source software (FOSS) landscape.

The report authors noted, “It is difficult to fully understand the health, economic value, and security of FOSS because it is produced in a decentralized and distributed manner.” Because there is such variety in the ways software components are packaged, as well as how versions are catalogued and identified, the report organized them into eight Top 500 lists. Mike McGuire, security solutions manager with Black Duck, describes packages and versions as being a bit like the model, year, and trim of a car. “If I told you I drive a Toyota Camry, you still don’t know exactly what I drive. Is it the 1999 version or the 2022 version? It’s important to know this when ordering parts, getting service, tracking recalls, etc.”

Purpose of Census II

The goal of Census II, according to the authors, is to “inform actions to sustain the long-term security and health of FOSS.” The census represents “our best estimate of which FOSS packages are the most widely used by different applications. […] It does not try to measure the risk profiles of that software. There are many indicators that could be used to suggest risk, and different organizations may weight factors differently,” the authors wrote.

McGuire agrees with the caveat. Widely used is not the same as critical. “Tons of apps can be using a specific Java GUI framework, making it very popular, but it may not serve as a critical part of the software should something happen to it.” He added that what is considered critical “is going to be unique to each organization based on how their apps are built.” Still, measuring risk profiles is “easier to do once the most widely used software is identified,” the Census II authors wrote.

Challenges of open source management

The authors outlined several hurdles to improving the way software is identified, catalogued, and maintained. These are important as the industry moves toward widespread standardization and adoption of a software Bill of Materials (SBOM). These challenges include

The need for a standardized naming schema for software components so that application libraries can be uniquely identified. The lack of such a schema means that “organizations will remain categorically unable to communicate with each other on the large scale—particularly, the global scale—necessary to share such information,” according to the report.

The complexities associated with package versioning. The authors encountered an unexpected problem: companies were “maintaining internal versions of a package and were not contributing their changes back to the official repository. In one instance, they observed version 2.87 of a package multiple times, but the official repository only went up to version 2.26,” the report noted. And if an SBOM “can’t distinguish between a ‘main’ version and a variant, […] it will be difficult for the purchasers of such software to know if they are vulnerable to newly discovered vulnerabilities.”

Issues affecting long-term security of free and open source software

The report also identified several problems that affect the long-term security of FOSS. These include

Much of the most widely used FOSS is developed by only a handful of contributors. Results in one dataset show that 136 developers were responsible for more than 80% of the lines of code added to the top 50 packages. The 2021 “Open Source Security and Risk Analysis” (OSSRA) report warns, “As an open source project grows in popularity—with no corresponding growth in people maintaining the project—the consequence is often developer burnout, and many open source projects are abandoned.” And if projects are abandoned, bugs don’t get fixed.

The importance of individual developer account security is increasing. Individual accounts generally aren’t as well-protected as organizational ones. That, the authors wrote, means “changes to code under the control of these individual developer accounts are significantly easier to make, and to make without detection. Further, a related issue could occur if the individual developer went on a long hiatus, or was hit by the proverbial bus, preventing updates to the code from occurring.” That’s not the only risk. For example, if a solo developer removed or deleted their projects, that could break hundreds to millions of packages that depend on it.
The persistence of legacy software in the open source space. We’ve all heard of companies declaring that they are ending support for older versions of operating systems or applications. But that doesn’t mean everybody stops using those older versions. “Many organizations will find it difficult to justify switching to different packages, since there are financial and time-related costs for switching to new software when there is no guarantee of an added benefit,” the authors wrote. The OSSRA report found that 85% of the codebases examined in 2020 had open source dependencies that were more than four years out-of-date, even though there were newer versions available—sometimes many newer versions. And that can be dangerous. One of the reasons for newer versions is to fix bugs in the older versions. You can be sure that hackers are looking for those still using the older versions.

McGuire said Census II “provides a view of popular FOSS and some observations about relative complexities.” While it is not prescriptive, Census II does point to the need for organizations and users to be more actively involved in FOSS development, and not leave it solely to the small group of developers who have led the way thus far. The report also shows how important software composition analysis (SCA) tools are to detect legacy software in open source, and the ongoing need for standardization in the SBOM space.