The call for adoption of memory-safe languages as a “secure by design” component has been issued once again by CISA and the NSA in a joint report that builds on prior guidance released by both agencies.
The report summarizes the benefits for organizations, with a particular focus on critical infrastructure partners, but also acknowledges common challenges that make the changeover a long-term goal and one that may never be 100% attainable. The agencies provide some concrete advice for tackling this gradual change, primarily recommending that new code be the focus instead of immediate conversion of existing codebases.
NSA, CISA advise on handling transition to memory-safe languages
Transitioning to memory-safe languages does provide the benefit of an inherent layer of security against buffer overflows, race conditions and the development of other similar memory vulnerabilities, but it is clearly not a simple proposition for organizations running on a built-up base of years of C++. The report acknowledges that the full transition will likely be a costly project that involves substantial investment in refactoring, tools and training.
The central advice of the report is to take it piece-by-piece, beginning with shifting new code development to something like Rust or Java. Rewriting existing codebases should be set to the side, possibly for a very long time; instead focus on developing new components and features in memory-safe languages, and aim for a more modest amount of rewrites carefully screened for interoperability needs and safety (critical components that are high-risk for attack and could be showstoppers if compromised).
The report includes a number of sources that back memory-safe languages having a major impact on limiting vulnerability development, but the biggest example is Google’s adoption of Java and Rust in Android development beginning in 2019. Prior to the changeover, 76% of the operating system’s vulnerabilities were some sort of memory issue. After five years of transition, that number was reduced to 24%. And as the CISA/NSA report recommends, Google undertook this by focusing on writing as much new code as possible in these languages rather than rewriting all of its existing codebases.
Barriers may weaken over time
The issues with shifting to memory-safe languages do go beyond merely the time and labor it would take to revamp existing codebases. There can be dependency issues with libraries or code-coupling issues with legacy systems that are not at all straightforward to resolve. And when components in these new languages have to communicate with components that remain in languages that are not memory-safe, there can be serious performance issues.
CISA and NSA hope that these issues will resolve gradually over time as voluntary adoption of memory-safe languages improve. The continual push for “secure by design” should both expand the offerings and compatibility of service providers (such as cloud infrastructure) and also reshape the workforce, with new coders immersing themselves in languages like Rust earlier in their careers and thus having a better handle on other secure design principles specific to them. While memory-safe languages can virtually eliminate certain classes of vulnerabilities such as these, that does not mean they are free from the possibility of other vulnerabilities caused by errant coding arising.
Though language changeover is a worthwhile goal to consider implementing, the reality for most organizations is that it will be a multi-year project and that mixed code environments will continue to be common and necessary for quite some time. This highlights the need for full visibility into the software supply chain, a more achievable first step with the help of modern automated tools and one that can yield immediate patching of existing vulnerabilities.
