Report reveals reliance on memory-unsafe languages in OSS projects
A collaborative report from several major cybersecurity organisations, including the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), the Australian Signals Directorate’s Australian Cyber Security Centre (ACSC), and the Canadian Centre for Cyber Security, has scrutinised the use of memory safety in critical open-source projects. Based on an analysis of 172 projects on the OpenSSF Securing Critical Projects Working Group’s List of Critical Projects, the findings reveal a significant reliance on memory-unsafe programming languages.
The report indicates that 52% of the analysed projects include code written in memory-unsafe languages. Additionally, 55% of the total lines of code across all projects fall under this category. The largest projects are particularly reliant on these languages, posing potential security risks. Furthermore, an analysis of three projects that employed memory-safe languages demonstrated dependencies on other components that were developed using memory-unsafe languages.
Chris Hughes, Chief Security Advisor at Endor Labs and Cyber Innovation Fellow at CISA, shared his insights on the matter. Hughes commented, “These findings are not surprising because of the long-standing use and pervasiveness of memory-unsafe languages in the software development ecosystem."
Hughes highlighted the ramifications of this dependence: “The findings certainly pose a risk to both commercial organisations and government agencies because of the prevalent exploitation of this class of vulnerabilities when we look at annual exploitation across classes of vulnerabilities (e.g. Common Weaknesses and Enumerations). They are often among the most commonly exploited class of vulnerabilities Year-over-Year.”
He added, “Reports like this are great to highlight the risks associated with memory-unsafe programming languages and their prevalence among OSS projects and components. To reduce risks, organisations need to thoroughly understand their OSS consumption as part of a broader software asset inventory. Organisations should understand the classes of vulnerabilities and how they are categorised, and make efforts to shift internally to memory-safe languages and adopt secure coding practices. They can also ask for transparency from their software suppliers to understand the risks in the software and products they consume when it comes to OSS.”
According to Hughes, the entrenched use of memory-unsafe languages presents a multifaceted challenge. He remarked, “Many of these projects are written in memory-unsafe languages for a variety of reasons. These include the pervasive long-standing use of memory-unsafe language in the development ecosystem. Often, these languages have been widely adopted and used for years before much of the recent activity to try and encourage the transition to memory-safe languages. Additionally, there is a need for the broader development community to transition to more modern memory-safe languages. It would be difficult to change many of these projects to memory-safe languages because it would require resources and efforts from the maintainers to refactor/rewrite to memory-safe languages. The maintainers may not have expertise in the memory-safe language and even if they do, they may not be incentivised to do so, given they are largely unpaid volunteers not being compensated for the projects they’ve created and maintained.”
Hughes also pointed out potential solutions, stating, “There are also opportunities for organisations to help facilitate the transition through resources including monetary incentives, as well as potentially development support to facilitate the transition. Of course, there still remain issues with third-party and transitive dependencies as discussed in the report, meaning even if the projects were re-written, they would need to conduct dependency analysis and ensure that transitive dependencies are also accounted for when it comes to memory safety. Lastly, efforts would need to be made to ensure the developers and maintainers implement secure coding practices to ensure memory safety safeguards aren’t undermined.”
The report underscores the importance of addressing memory safety issues in open-source projects, especially considering their critical nature and widespread use. It calls for a concerted effort from organisations and the broader development community to transition to newer, safer programming practices while maintaining transparency and a thorough understanding of their software ecosystems.
