Memory safe programming languages are on the rise. Here's how developers should respond

Developers across government and industry should commit to using memory safe languages for new products and tools, and identify the most critical libraries and packages to shift to memory safe languages, according to a study from Consumer Reports.

The US nonprofit, which is known for testing consumer products, asked what steps can be taken to help usher in "memory safe" languages, like Rust, over options such as C and C++. Consumer Reports said it wanted to address "industry-wide threats that cannot be solved through user behavior or even consumer choice" and it identified "memory unsafety" as one such issue. 

The report, Future of Memory Safety, looks at range of issues, including challenges in building memory safe language adoption within universities, levels of distrust for memory safe languages, introducing memory safe languages to code bases written in other languages, and also incentives and public accountability.       

Also: Programming languages: Why this old favorite is on the rise again

During the past two years, more and more projects have started gradually adopting Rust for codebases written in C and C++ to make code more memory safe. Among them are initiatives from Meta, Google's Android Open Source Project, the C++-dominated Chromium project (sort of), and the Linux kernel. 

In 2019, Microsoft revealed that 70% of security bugs it had fixed during the past 12 years were memory safety issues. The figure was high because Windows was written mostly in C and C++. Since then, the National Security Agency (NSA) has recommended developers make a strategic shift away from C++ in favor C#, Java, Ruby, Rust, and Swift.  

The shift towards memory safe languages -- most notably, but not only, to Rust -- has even prompted the creator of C++, Bjarne Stroustrup and his peers, to devise a plan for the "Safety of C++". Developers like C++ for its performance and it still dominates embedded systems. C++ is still way more widely used than Rust, but both are popular languages for systems programming.  

The Consumer Reports study includes input from several prominent figures in information security, as well as representatives from the Cybersecurity and Infrastructure Security Agency (CISA), Internet Security Research Group, Google, the Office of the National Cyber Director, and more. 

The report highlights that computer science professors have a "golden opportunity here to explain the dangers" and could, for example, increase the weight of memory safety mistakes in assessing grades. But it adds that teaching parts of some courses in Rust could add "inessential complexity" and that there's a perception Rust is harder to learn, while C seems a safe bet for employability in future for many students. 

The report suggests the industry could gain data on the companies that are hiring people who know memory-safe languages, and those who require C/C++, by inspecting a software bill of materials (SBOM). 

To overcome programmers' belief that memory safe languages are more difficult, someone could explain that these languages "force programmers to think through important concepts that ultimately improve the safety and performance of their code," the report notes. 

Also: 'Find something you're passionate about.' Five ways to build a career path that works for you

The report also addresses the question of how to bring a new language to an existing code base. The Linux kernel project is not rewriting existing kernel code, but enabling Rust for some drivers initially. The Chromium security team is cautiously enabling Rust where it makes business sense, and also building memory safety features for C++ code in Chrome. The Android Open Source Project is pushing Rust more aggressively. In Android 13, 21% of new code is written in Rust, but C and C++ code still dominate.  

The report says that companies should be transparent about the causes of bugs, providing detailed information on security vulnerabilities to help researchers and industry experts ascertain which percentage of vulnerabilities are due to memory safety. 

But knowing where to start will be difficult because vulnerability disclosures generally don't provide enough information to link the cause of a flaw to a particular language. 

"For example, Apple's security bulletins currently don't provide enough details to distinguish C/C++ induced memory vulnerabilities from logic bugs," it notes. 

The report acknowledges an industry belief that social and commercial incentives that are needed to fully address a problem of this scale do not exist.  

It also imagines a world where "memory-safe" procurement regulations do exist. Today, it notes, you can't buy routers written entirely in memory safe languages because no such products exist. 

"But it may be possible for the government to say that newly developed custom components have to be memory-safe to slowly shift the industry forward. This would require some type of central coordination and trust in that system. The government could ask for a memory safety road map as part of procurement. The map would explain how the companies plan to eliminate memory-unsafe code in their products over time," it notes. 

Ideas to push the adoption of memory safe language use include getting developers to list the memory safety mitigations used by a piece of software, as well as a "nutrition label" approach to indicate what percentage of code is covered by safe languages, audits, fuzzing, sandboxing, least privilege, and more. 

It also recommends regulatory and monetary incentives for organizations to transition legacy code to memory safe languages.