Adversarial exposure · Determinism
Write new code in a memory-safe language
The share of vulnerabilities caused by memory unsafety tracks the language new code is written in, not the language the codebase is written in — one platform went from 76% of vulnerabilities being memory-safety issues in 2019 to 24% in 2024 while the bulk of its code remained unsafe.
Do this firstNothing. This is a place to start.
Leave the old code alone. Write the new code somewhere else.
Two independent organisations put memory unsafety at about 70% of their serious vulnerabilities — one across CVEs fixed by security update over more than a decade, the other across 912 high and critical bugs. That is the baseline this control moves.
What makes it adoptable is the third measurement. The platform that changed its number did not rewrite anything: it changed what new code was written in, and the annual count of memory-safety vulnerabilities fell from 223 to 85 over three years. The mechanism is that vulnerabilities concentrate in new code, so the language of new code sets the rate even while the old code sits there.
Their own word is “correlate”, not cause, and the honest reading is that the confound — teams adopting a new language are also teams doing other things — has not been ruled out.
The decoy
Rewriting the old code. It is the version of this everyone imagines, it is usually infeasible, and it is not what produced the measured result — the codebase that halved its vulnerability rate is still majority memory-unsafe.
Evidence
- Eliminating Memory Safety Vulnerabilities at the Source — IIMemory-safety issues fell from 76% of vulnerabilities in 2019 to 24% in 2024, with the annual count dropping from 223 to 85 over 2019-2022, while the codebase remained majority memory-unsafe. The change tracks the language new code is written in rather than any rewrite of existing code.
- Chromium: memory safety — IIAround 70% of high and critical severity security bugs are memory-unsafety problems, and about half of those are use-after-free.
- Trends, challenges, and strategic shifts in the software vulnerability mitigation landscape — IIAbout 70% of the vulnerabilities addressed through a security update each year continue to be memory-safety issues, across patch years 2006 to 2018. The leading root causes since 2016 are heap out-of-bounds access, use-after-free, type confusion and uninitialised use.
Last reviewed 2026-08-19.