memory safety
termprogrammingsecurity
The property of never accessing memory outside what a program legitimately owns, in space or in time.
Two halves: spatial safety means staying inside an object's bounds, and temporal safety means only touching it while it is alive, which is why buffer overflows and use-after-free are the same problem viewed on different axes. The industry conclusion, stated by CISA, the NSA, and Microsoft alike, is that roughly seventy percent of serious vulnerabilities in large C and C++ codebases are memory-safety bugs, which is what put Rust, Go, Java, and modern C++ practice at the center of the conversation. Rewriting everything is not realistic, so the practical answer is memory-safe languages for new components plus hardening and sanitizers for the code that stays.
Memory safety means a program cannot read or write outside what it legitimately owns. Languages that guarantee it eliminate overflows, use-after-free, double frees and data races on memory by construction rather than by discipline.
The numbers behind the industry's shift are stark: multiple large vendors have reported that around two thirds of their serious vulnerabilities are memory safety issues, and that proportion has been stable for years despite enormous investment in finding them. That is the argument for changing the material rather than inspecting it harder. The honest counterweight is that rewriting working systems is expensive and risky, which is why the practical advice is to write new components in safe languages and to harden rather than replace the old ones.
Also known as: memory-safe language, spatial safety, temporal safety