Memory safety in the release notes

What happened

In December 2023, CISA, the NSA, the FBI, and the cybersecurity agencies of Australia, Canada, New Zealand, and the United Kingdom published The Case for Memory Safe Roadmaps. The guide says memory safety bugs are still the most common class being disclosed, and that another round of patches has not retired the class. It asks software makers to publish a roadmap: which new code will be written in a memory-safe language, what happens to the code that is not, and which executive owns the date. In June 2025, CISA and the NSA followed with a second guide on the obstacles that stop that roadmap from being a slogan: missing libraries, weak tooling, and training. This page files those two documents and the Microsoft measurement they sit beside. It is not a copy of any of them. The paper that holds the brief is Futureweb.

The class of bug

Memory safety, in the sense a release note has to mean if it is going to be testable, is about a program touching memory it did not mean to touch. An out-of-bounds read or write steps off the end of a buffer. A use-after-free uses an object after the program said it was finished. A double-free frees the same object twice. Uninitialized memory treats leftover bytes as a real value. Type confusion treats a stored value as a different type. A note that says memory safety and names none of these is a mood. A note that says the language or the compiler rejects them, in the code that reads untrusted bytes, is a constraint. The reader can check the constraint against the next build. The mood cannot be checked.

What a roadmap asks for

The 2023 guide is specific about the document. It wants an evaluation of memory-safe languages, a pilot, a date after which new code in the product is written in one of them, a plan for the code that already exists, a plan for dependencies, training, and a way for a customer to see what changed. Publishing the date is the point, because a customer cannot audit a feeling. A post that praises memory safety and names no date, no language, and no boundary around the remaining unsafe code has not met the list. The 2025 guide is about the reasons a list like that fails in practice: the library the team needs does not exist in the new language, the tools are thin, and the people who maintain the parser have not been taught. Both pages are in the sources. This brief is the desk's account of what they ask, not a second copy of the PDF.

Why it matters on this desk

The software desk files a release when the change is in the software a person ships. Memory safety belongs on that desk when a note changes what the toolchain will accept, or when a public guide tells vendors to publish that change as a date. A keynote line does not belong here. The reader has to decide whether a dependency's next version still parses untrusted input in a language that allows the class, and whether any unsafe remainder is marked and shrinking. Later notes on the same question stay on this desk, Software.

Parsers and untrusted bytes

The bugs in this class gather where a program reads bytes it did not create: a file, a packet, a document, a message from another process. A memory-safety promise that covers the interface and leaves the parser in C or C++ has not moved the risk the guides describe. When that parser fails in public, the bug, the affected versions, and who can reach it are filed as the advisory.

The proportion the vendors published

Microsoft's Security Response Center wrote in July 2019 that about 70 percent of the vulnerabilities it fixes and assigns a CVE each year were still memory safety issues, after years of review, training, and static analysis. That figure is Microsoft's triage of Microsoft software. It is not a count of every codebase. CISA's 2023 guide says two-thirds of reported vulnerabilities in memory-unsafe languages still relate to memory issues. The numbers are close, and they are not the same measurement. Averaging them into "70 percent of all bugs" is a false precision this desk will not print. What both support is narrower: in large bodies of C and C++, the class did not yield to tools and training alone. Advisories that come out of that class are filed on Security.

What to watch next

Watch the next release note of a parser, a kernel boundary, or a library that handles untrusted bytes. The sentence worth filing names a language, a date for new code, and what remains explicitly unsafe. "We take memory safety seriously" is not that sentence. A roadmap with a date can still slip, and the slip is a later story. The absence of a date is already information. So is a date that covers only new products while the parser customers actually run is left unnamed. The desk will treat those as different facts, because a reader who mixes them will think a migration has started when only a preamble has been published.

Where the sources disagree

Microsoft's 2019 series argues that a memory-safe language removes bugs that review did not remove, and it discusses Rust as that language. CISA's roadmap does not crown a language. It asks for a published migration, including dependencies and the code that stays unsafe for a while. A vendor can match the Microsoft argument and still miss the CISA list, or publish a CISA-shaped plan that names a language the team does not ship yet. This brief does not pick the winner. It files the disagreement: one source is one company's CVE share plus a language recommendation, and the other is a template any manufacturer can be held to. When a later brief is about the rebuild of a component in a memory-safe language, the catalog of those primitives is Remade with Rust.

What is still unknown

A release note is not the repository. This brief cannot see whether the date in a roadmap matches the code that parsed last quarter's bug. The next check is ordinary: take the component named in the note, read the following advisory, and see whether the failure is still the same class. Until that advisory exists, the note is a claim. If the project is public, the same claim is also a release on Open Source.