The country’s top cybersecurity agency is continuing to urge software developers to adopt memory-safe programming languages to help reduce the number of vulnerabilities in their products, most recently through a report showing that more than half of widely used open-source projects contain memory-unsafe code.

CISA and the FBI also found that 55% of the lines of code in the projects were written in memory-unsafe languages and that the largest projects disproportionately were written in such languages. In addition, even projects that were said to be programmed in memory-safe languages included some components created with memory-unsafe code.

In the joint 22-page report released this week and developed in conjunction with counterparts from Canada and Australia, the agencies recommended software makers create roadmaps for transitioning to memory-safe roadmaps, including plans for addressing memory safety in external dependency, which tend to include open-source software (OSS).

The report, “Exploring Memory Safety in Critical Open Source Projects,” “provides a starting point for these roadmaps by investigating the scale of memory safety risk in selected OSS,” the agencies wrote.

CISA and other government agencies for more than a year have been beating the drum for memory-safe languages, encouraging developers to migrate away from C and C++ and adopting such languages as Rust, C#, Go, Java, Python and Swift.

A Needed Change

Such a transition will eliminate many of the memory safety issues that have haunted software developers for decades and account for the most common flaws in software, according to CISA. These vulnerabilities affect how memory is accessed, written, or allocated in ways never intended in the programming languages.

They can lead to more updates, patching and incident responses that can cost both the software maker and their users. The vulnerabilities also open up the software to exploitation by bad actors. The flaws can include buffer overflows, use of uninitiated memory and use after free.

Memory-safe languages essentially prevent programmers from creating code that can lead to memory bugs and security flaws by including features that automatically catch memory access errors, like dangling pointers and buffer overflows, at the compile time and runtime stages. C, C++, and similar non-memory safe languages don’t have such automatic functions, which leads to more bugs ending up in the final version of the code.

“Memory-unsafe languages require developers to properly manage memory use and allocation,” the agencies wrote in the report. “Mistakes, which inevitably occur, can result in memory-safety vulnerabilities such as buffer overflows and use after free. Successful exploitation of these types of vulnerabilities can allow adversaries to take control of software, systems and data.”

That said, “memory-safe languages shift the abstraction layer and responsibility for writing memory-safe code from the developer to the compiler or interpreter, vastly reducing opportunities to introduce memory-safety vulnerabilities.”

More Work to Be Done

The 172 open-source projects analyzed came from the Open Source Security Foundation (OpenSSF) Securing Critical Projects Working Group’s list of critical projects.

The agencies found that even for projects written in memory-safe languages, there still can be memory safety flaws.

“This can be caused by direct use of memory-unsafe languages or external dependency on projects that use memory-unsafe languages,” they wrote. “Additionally, low-level functional requirements to disable memory safety may create opportunities for memory safety vulnerabilities in code written in otherwise memory-safe languages. These limitations highlight the need for continued diligent use of memory-safe programming languages, secure coding practices and security testing.”

Not Always an Easy Transition

Neatsun Ziv, co-founder and CEO of OX Security, said he wasn’t surprised that many of these projects use memory-unsafe languages. A barrier to shifting to memory-safe code is the prevalence of legacy systems built with C and C++.

“Rewriting these in modern, memory-safe languages is not only costly but also complex, potentially leading to disruptions in critical business operations,” Ziv said. “The key challenge lies in balancing enhanced security with the financial implications.”

He recommended companies create detailed plans for migrating to memory-safe languages, including prioritizing the most critical components first. In addition, they should use advanced code analysis tools and compilers to automatically detect and correct unsafe coding practices and establish clear governance frameworks that integrate memory safety and secure coding practices across the software development lifecycle.

“Focusing on memory safety is crucial for enhancing the security of future software development,” Ziv said. “However, transitioning from existing systems involves significant upfront investment and careful weighing of costs, benefits, and potential security compromises for each organization, which is why it’s taking a significant amount of time for enterprises to make the switch.”

Building the Case

The report builds on another document, “The Case for Memory Safe Roadmaps,” which CISA and agencies in other countries released in December 2023. CISA Director Jen Easterly at the time put adopting memory-safe coding into national security terms and said it was a key part of the federal government’s Secure By Design initiative to encourage developers to integrate security capabilities throughout the entire software development lifecycle rather than bolting it on at the end.

It also in line with another push by the Biden Administration to lift the responsibility of securing software and other technologies from the users and put it on the shoulders of developers.

In February, the White House issued a technical report that reinforced the argument that greater use of memory-safe languages would eliminate a range of security flaws, with National Cyber Director Harry Coker saying in a statement that “we, as a nation, have the ability – and the responsibility – to reduce the attack surface in cyberspace and prevent entire classes of security bugs from entering the digital ecosystem.”