Census II examines the most popular components of free and open source software and highlights issues affecting the security of these libraries.
Last week, the nonprofit Linux Foundation and Harvard’s Lab for Innovation Science released Census II of Free and Open Source Software—Application Libraries. This report identifies over 1,000 of the most widely deployed open source application libraries. Synopsys Cybersecurity Research Center (CyRC) was among the contributors of anonymized usage data based on codebase analytics across thousands of companies, providing data that helped to get a more complete picture of the software landscape free and open source (FOSS).
The report’s authors noted, “It is difficult to fully understand the health, economic value, and security of free software because it is produced in a decentralized and distributed fashion.” Because there is such variety in the ways software components are packaged, as well as how versions are cataloged and identified, the report has organized them into eight Top 500 lists. Mike McGuire, Head of Security Solutions at Synopsys Software Integrity Group, describes packages and versions as being much like the model, year and finish 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? This is important to know when ordering parts, obtaining service, tracking recalls, etc.
Purpose of the Census II
The purpose of Census II, the authors say, is “to inform actions to maintain the long-term safety and health of FOSS.” The census represents “our best estimate of the most widely used FOSS packages by different applications. […] It does not attempt to measure the risk profiles of this software. There are many indicators that could be used to suggest risk, and different organizations may weight the factors differently,” the authors wrote.
McGuire agrees with the caveat. Widely used is not the same as critical. “Tons of applications can use a specific Java GUI framework, which makes it very popular, but it might not serve as an essential part of the software if something happened to it.” He added that what’s 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.
The challenges of open source management
The authors pointed out several barriers to improving the way software is identified, cataloged, and maintained. These are important as the industry moves towards widespread standardization and adoption of software bill of materials (SBOM). These challenges include
- The need for a standardized naming scheme for software components so that application libraries can be uniquely identified. The absence of such a scheme means that “organizations will remain categorically unable to communicate with each other on the large scale – especially on a global scale – necessary to share this information,” according to the report.
- The complexities associated with versioning packages. The authors encountered an unexpected problem: companies “maintained internal versions of a package and did not return their changes to the official repository. In one case, they observed version 2.87 of a package multiple times, but the official repository only upgraded to 2.26,” the report noted. And if an SBOM “cannot distinguish between a ‘main’ release and a variant, […] it will be difficult for purchasers of such software to know if they are vulnerable to newly discovered vulnerabilities.
Issues Affecting the Long-Term Security of Free and Open Source Software
The report also identified several issues that affect the long-term security of FOSS. These include
- Most popular free software is developed by just a handful of contributors. Results from a 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 – without a corresponding growth in the number of people maintaining the project – the consequence is often burnout. developers and many open source projects are abandoned. .” And if the projects are abandoned, the bugs are not fixed.
- The importance of individual developer account security is increasing. Individual accounts are generally not as well protected as those of organizations. This, the authors write, means that “changes to code under the control of these individual developer accounts are much easier to make and go undetected.” Additionally, a related problem could arise if the individual developer takes a long break or gets hit by the proverbial bus, preventing code updates from happening. This is not the only risk. For example, if a solo developer deleted or deleted their projects, it could break hundreds to millions of packages that depend on them.
- The persistence of legacy software in the open source space. We’ve all heard of companies saying they’re ending support for older versions of operating systems or applications. But that doesn’t mean everyone stops using those older versions. “Many organizations will struggle to justify switching to different packages, as there are financial and time costs to moving to new software when there is no guarantee of additional benefit,” wrote writers. The OSSRA report found that 85% of codebases reviewed in 2020 had open source dependencies that were out of date for more than four years, even though there were newer versions available, sometimes many newer versions. And it can be dangerous. One of the reasons for new releases is to fix bugs in older releases. You can be sure that hackers are looking for those who are still using older versions.
McGuire said Census II “provides a view of popular free software and some observations on the relative complexities”. Although not prescriptive, Census II emphasizes the need for organizations and users to become more actively involved in the development of FOSS, and not leave it solely to the small group of developers who paved the way so far. ‘now. The report also shows how important Software Composition Analysis (SCA) tools are for detecting legacy open source software, and the continued need for standardization in the SBOM space.