Memory-safe languages have been a topic of discussion in recent weeks. Last week the White House published this report espousing the benefits of using memory-safe languages as the foundational building block of developing secure software.
In practice, memory-safe languages improve the security of an application by eliminating memory corruption vulnerabilities such as buffer overflows and dangling pointers. While memory-safe languages do not remove all security vulnerabilities, it’s important to note that non memory-safe languages to make up 70% (MSRC, Chromium, Android) of the vulnerabilities found in software.
Popular memory-safe languages including JavaScript, Python, Java, and C# all ranked higher than C and C++ (the most used unsafe languages) as the most used languages by professional developers in 2023. In fact, the industry overall has been moving to memory-safe languages over the last 20 years. However, C and C++ are still very popular languages for developing software even though they are not memory safe. In the next sections, we explore the reasons they are still used.
Crucial software that powers our world often exceeds 100,000 lines of C and C++ code, with some of the most important pieces of software reaching into the 10s of millions including the Linux kernel with 27 million lines of C and Windows 11 with over 50 million lines of C/C++.
One thing to consider is the time and cost associated with rewriting large codebases in a different language. The high level of effort reduces the amount of time engineering resources can spend on new feature development, creating a tradeoff that commonly results in a focus on new features. This decision is often driven by the ease of estimating additional revenue from a new feature compared to calculating the probability of an exploitable vulnerability and its revenue impact. If a complete rewrite is not possible, then using a memory-safe language to develop new products and components may be the best option.
Another tradeoff to consider is the software engineering team’s skillset with a specific language. If the team that develops and maintains the codebase is skilled in a language that is not memory-safe, migrating to a memory-safe language may significantly impact the productivity of the team as they work to become efficient in the new language. This can also introduce vulnerabilities in the software.
Another important item to consider is team dynamics. There may be pushback from some members who are experts in the current language, offering the perspective that their skillset reduces the risk. It took time and effort for them to acquire those skills so the thought of not regularly programming in that language and becoming a beginner in the new language can be unsettling.
Fortunately, the skills acquired from learning one programming language often carry over to others, making the process of mastering a new language not only a valuable skill but also an enriching experience. It allows teams to discover diverse and innovative approaches to tackling common development challenges.
It is possible to build secure applications without using a memory-safe language. This is the argument that many software engineering teams make that want to keep developing in a memory unsafe language such as C++.
Although true, it takes expert software engineers and a focused development effort to succeed, and unfortunately, as the size of the project and the number of developers contributing increases, so does the complexity and the probability of introducing a memory vulnerability. This applies even if you are using modern C++ types and idioms such as smart pointers and RAII.
Because of the guarantees provided by memory-safe languages, software teams can allow even junior software engineers to contribute to large and complex projects without auditing every memory access. This allows the team to move faster by focusing on developing and reviewing the business logic of the application, not low-level memory access details.
The C and C++ programming languages have been the primary choice for developing high-performance software for decades, despite memory-safe languages being available as they were not performant enough for systems development.
The Rust programming language changed that. Rust is memory-safe and high-performance. Its first stable release 1.0 was in 2015; however, like any new language, it takes time to build an ecosystem. Today many large technology companies are using it to develop system software such as Google, Amazon Web Services, Facebook, and Microsoft. Thus, software engineers now have a memory-safe language that is high-performance and mature enough to replace most C and C++ system development.
Here at Todyl, memory-safe languages are used for most of the code that we write, with Go being the most used language across the engineering teams. It is used to write everything from our backend APIs to the control plane for packet processing, however we do, and will continue to leverage codebases written in C/C++ for high performance applications, such as packet processing across our SASE Secure Global Network, and applications that require deep integration with operating systems. The performance and capabilities of these limited codebases allow us to deliver a more performant, more reliable platform despite the additional cost and time associated with development.
Using memory-safe languages to develop software will significantly reduce the possibility of introducing a memory corruption vulnerability in applications and we agree with the report that outside of rare requirements, new codebases should use a memory-safe language.
These rare exceptions include large legacy codebases may be too costly to rewrite completely in a memory-safe language. However, new components can be written in a memory-safe language and integrated with the existing system. Initially, this will be more work for the development team but will reduce the memory-unsafe code and will begin the migration of the codebase to a memory-safe language. All in all, using a memory-safe language will not eliminate all vulnerabilities but should reduce a significant fraction.
Read our blog to see the ways Todyl Engineering is using memory-safe languages to advance our product.
