Memory Safety

Every program temporarily stores its data in the computer’s memory. In doing so, things can go wrong: a program reads data from a memory region that doesn’t actually belong to it. It writes beyond the boundaries of a reserved region. Or it tries to use memory that it has already freed. Such errors are called memory access errors. A language or environment is considered “memory-safe” if it makes this class of errors technically impossible — either already at the time the program is compiled or, at the latest, when it is executed.

Memory safety as an underestimated vulnerability

The US Cybersecurity and Infrastructure Security Agency (CISA) estimates that around 70 percent of all critical security vulnerabilities in large software can be traced back to memory access errors. These include errors such as buffer overflow: an attacker sends more data than is intended for a given memory region, deliberately overwriting adjacent regions with their own malicious code. The program then unknowingly executes this code. It is precisely such attacks that have compromised operating systems, browsers, and industrial control systems in the past.

The core of the problem: in languages like C or C++, the programmer themselves is responsible for requesting memory, using it correctly, and releasing it again. Humans make mistakes doing this. And a single mistake can be enough to make an entire system vulnerable to attack.

How languages prevent memory errors

There are two fundamental approaches. The first is automatic memory management, a so-called garbage collector: the program’s runtime system continuously observes which memory regions are still needed and automatically frees the rest. Java, Python, and Go work this way. The programmer doesn’t have to take care of this themselves — and can therefore simply no longer make certain mistakes. The downside is a certain computational overhead that runs permanently in the background.

The second approach checks memory accesses not at runtime, but already when the source code is compiled into executable files. The programming language Rust takes this route. Its compiler — the program that converts source code into an executable file — analyzes before execution whether every memory access is valid. Programs that fail this check cannot even be started in the first place. Rust thus achieves memory safety without the runtime overhead of a garbage collector — which is particularly attractive for performance-critical systems.

A common misconception: memory safety does not mean that a program can no longer have any errors. Logic errors, incorrect calculations, or faulty database queries are not affected by it. Memory safety rules out exactly one class of errors — but it is the class most frequently responsible for severe security vulnerabilities.

Memory safety in current debates and products

The topic has gained considerable political weight in recent years. In 2024, the US government recommended in an official report that memory-safe languages be preferred going forward. Microsoft stated that around 70 percent of reported security vulnerabilities in Windows can be traced back to memory access errors — and has begun writing new components in Rust. Google is doing the same for parts of the Android operating system.

Memory safety also plays a role in the field of AI infrastructure. Many libraries that train or run neural networks are written in C++ for speed reasons — that is, in a language without automatic memory safety. The industry is discussing whether switching to safer languages there is practically feasible without losing too much computing performance.

For users, memory safety is invisible — they only notice something at all when it is absent: through a crash, through a system behaving strangely, or through a headline about an exploited security vulnerability that could have been avoided with a different language design.