Significant security risks continue to be prevalent in open source software practices, a new report by the Linux Foundation, OpenSSF and Harvard University has found.
The CENSUS III project was based on 12 million observations of free and open source software (FOSS) libraries used in production apps at over 10,000 companies. It highlighted a number of concerning cybersecurity practices relating to open source software, which is widely used across all industries.
The project aims to provide a clearer picture of the structural issues that threaten the FOSS ecosystem.
The analysis is the third of its kind, following the publications of CENSUS I and II in 2015 and 2022, respectively.
Risky Practices in Open Source Software
Ongoing Reliance on Outdated Python 2 Language
The researchers observed ongoing issues with the transition from the Python 2 to Python 3 programming language, despite the latter being officially released in 2008. For example, there are high proportions of Python 2 users in sectors like data analysis (29%), computer graphics (24%), and DevOps (23%).
This is causing major cybersecurity risks as Python 2 is no longer supported by the Python developers, including for security vulnerabilities.
Lack of Standardized Naming for Software Components
The report highlighted a continued lack of a standardized naming scheme for software components, previously identified in CENSUS I and II. The researchers described the naming conventions for software components as “unique, individualized and inconsistent.”
This lack of standardization makes it harder for industry and government to protect themselves from software-based incidents, particularly as software bills of materials (SBOM) and other software supply chain transparency and security efforts continue to grow, mature and become more complex.
This is largely because organizations cannot communicate with each other on a global scale to share software security information without such a scheme in place.
“There is a critical need for a standardized software component naming scheme that is in widespread use. Until one is widely used, strategies for software security, transparency and more will have limited effect,” the researchers wrote.
Open Source Security Dependent on Handful of Contributors
CENSUS III also found that the security management of open source software tends to be dependent on a tiny number of contributors.
For example, in the year 2023, 17% of projects had one developer accounting for more than 80% of commits authored while 40% of projects had only one or two developers accounting for more than 80% of commits authored.
Additionally, there are few prolific developers who are responsible for a large percentage of the commits across multiple top components. The researchers believe these insights should change how organizations view the security of open source projects.
Heavy Reliance on Individual Developer Accounts
Many of the software packages analyzed for the study were hosted under individual developer accounts. This poses significant security risks, as individual developer accounts tend to have fewer protections associated with them than organizational accounts.
For example, they often do not employ measures like multifactor authentication (MFA) and do not have the same granularity of permissioning and other publishing controls.
The researchers added that developer account takeovers are now occurring with “increasing frequency.”
Legacy Software Remains Prevalent
Another major security risk with open source software is the persistence of legacy software in this ecosystem, according to the report. While software should theoretically be easier to replace compared to hardware, this is not always the case as replacement packages often have different application programmable interfaces (APIs) and somewhat different functionality.
This legacy software poses huge risks to organizations as the number of developers working to ensure security updates decreases as the software gets older.
Rust Adoption Surges Amid Shift to Memory-Safe Programming
A positive finding from the report is that there has been a 500% increase in the number of Rust components being used since CENSUS II.
This follows efforts by US federal government agencies to push for the transition to memory safe programming languages, as the C and C++ languages do not prevent memory safety errors by default.
Eliminating these languages would be estimated to prevent up to 70% of memory safety vulnerabilities occurring.
Read now: Majority of Critical Open Source Projects Contain Memory Unsafe Code
The most popular alternative to C and C++ is Rust, as this language has a package management system, making it easier to determine dependencies.
“The drastic increase in direct Rust application components since Census II points to increased adoption of the Rust language. This is significant progress towards using more memory-safe languages in open source software,” the researchers noted.