Memory-safety vulnerabilities remain one of the most persistent and costly risks in large-scale C++ systems, even in well-tested production code. This article explores how hardening the C++ Standard Library—specifically LLVM’s libc++—can deliver meaningful security and reliability gains at massive scale with minimal performance overhead.

Practical Security in Production: Hardening the C++ Standard Library at massive scale

by Louis Dionne, Alex Rebert, Max Shavrick, and Konstantin Varlamov

From the article:

Over the past few years there has been a lot of talk about memory-safety vulnerabilities, and rightly so—attackers continue to take advantage of them to achieve their objectives. Aside from security, memory unsafety can be the cause of reliability issues and is notoriously expensive to debug. Considering the billions of lines of C++ code in production today, we need to do what we can to make C++ measurably safer over the next few years with as low of an adoption barrier as possible.

In 2019, Alex Gaynor, a security expert and one of the leading voices in memory safety, wrote a piece titled "Modern C++ Won't Save Us," where he gave examples of foundational types such as std::optional that were unsafe in the idiomatic use cases. What happens when these unsafe types are used beyond their contract? Well, you guessed it: undefined behavior. The std::optional type isn't the only one to behave like this. If you look at how this compares with modern languages, you can see that C++ is the outlier.

So, what's to be done? Possibly one of the best places to start today is by improving our standard libraries. They provide the baseline "vocabulary types" for developers—and if they're not safe, it will be tough to build safety around them. The std::optional type is only one of many vocabulary types in the C++ Standard Library that aren't safe by default today. Given the current state, it seems mostly clear that the first step should be hardening our standard library, and in our case, this was LLVM's libc++.