Skip to content

White House ONCD "Back to the Building Blocks" (February 2024)

The White House Office of the National Cyber Director's memory-safety report and the C/C++-adverse federal stance.

memory-safety industry

§1 Provenance

§2 Claim

The report’s central claim is a dual call to action:

  1. Adopt memory-safe languages. Memory-safe languages are the most effective single intervention for reducing memory-safety vulnerabilities at scale. The report explicitly names C and C++ as examples of memory-unsafe languages and Rust as an example of a memory-safe language.
  2. Improve software measurability. The research community should make progress on the hard problem of measuring software cybersecurity quality — so that procurement officers, regulators, and customers can compare products meaningfully.

The report frames memory-safety vulnerabilities as a 35-year problem: from the Morris worm (1988) through Slammer (2003), Heartbleed (2014), Trident (2016), and BLASTPASS (2023) — all rooted in memory-safety bugs. It cites Microsoft and Google studies that “approximately 70 percent of all security vulnerabilities are caused by memory safety issues”.

The report distinguishes spatial memory-safety bugs (out-of-bounds access) from temporal bugs (use-after-free, double-free, race-on-free) and notes that both must be addressed.

The report carves out a careful exception for space systems, noting three constraints (close-to-kernel, deterministic timing, no garbage collector) and acknowledging that “at this time, the most widely used languages that meet all three properties are C and C++”. This is the report’s only explicit concession to legacy C/C++ use.

§3 Scope and Limits

Scope. Federal-government technology procurement, US software-industry direction-setting, research community framing. The report is technical and aspirational, not regulatory.

Limits. No enforcement, no procurement clauses, no funding attached. It is a signal, not a rule. The “C/C++-adverse” framing is real but rhetorical: the report does not ban C/C++ acquisition, and its space-systems carve-out shows the authors were aware of the impracticality of a hard ban. Critics — most notably the ISO C++ Directions Group — pointed out that memory safety is “a very small part of security” and argued for the in-progress C++ Profiles work as an alternative path.

§4 May 2026 Status

Has not been formally re-issued as of May 2026 by the current administration. The original Biden-era report sits on the National Archives mirror; the document text has not been retracted, and the policy direction has been reinforced by subsequent NSA + CISA guidance (June 2025 CSI) and by the DoD SWFT framework (2025). The Biden-era ONCD also issued related letters / requests for information on open-source security and software measurability.

The 2025 NSA-CISA joint CSI explicitly cites the 2024 ONCD report as a baseline, treating it as the canonical White House position even after administration change. No new ONCD report has been issued that this research has surfaced.

C++ continues to evolve with Profiles (Stroustrup’s proposed mechanism for selectively restricting unsafe C++ features at compile time), targeting C++26 and beyond. This is the C++ ecosystem’s own response to the ONCD pressure. Whether it satisfies the ONCD criteria remains debated; the ONCD report’s authors did not endorse Profiles as a substitute for memory-safe languages.

§5 Cost

The cost of producing the report is negligible (a small ONCD technical-report effort). The industry cost is enormous and largely indirect: the report’s signalling effect contributes to multi-billion-dollar memory-safe-language adoption efforts at major vendors. The exception carve-out for space systems means specialist domains face no direct conversion pressure, but the broader software market does.

For a small project like Mochi, the “cost” is zero — Mochi is memory-safe by construction. The cost to anyone using Mochi is the same as adopting any other memory-safe language.

§6 Mochi Adaptation Note

The ONCD report is the single most authoritative White House signal on memory safety, and Mochi should explicitly align with it.

  • The C/C++-adverse stance is what MEP-41 should explicitly endorse. Mochi is in part a response to the same observation: dynamic languages and Go-style languages are memory-safe by construction; C and C++ are not; the cost of bug-fixing in C/C++ is unbounded. MEP-41 can quote the report’s framing.
  • The “spatial vs temporal” distinction is the right vocabulary. MEP-41 should use this terminology when discussing Mochi’s Cell design: the (base, slab_idx) component handles spatial safety; the generation tag handles temporal safety. Both are first-class concerns, both are explicitly addressed by the Cell design, and the ONCD report is the right citation.
  • The “memory safety is the dominant single CWE category” framing is the right rhetorical move. MEP-41 can use the ONCD’s 35-year vulnerability history as the motivating story for why a new language warrants a new runtime design.
  • The space-systems carve-out is irrelevant to Mochi. Mochi is not aimed at hard-real-time embedded systems. MEP-41 need not engage with the carve-out except to note that Mochi targets the general-application space the report applies to.
  • The “software measurability” leg of the ONCD report is interesting for Mochi. ONCD asked the research community to make progress on measurability. Mochi can contribute one tiny piece: publishing memory-safety-relevant data about Mochi-runtime issues over time. MEP-41 can commit to this as a contribution to the measurability agenda.

§7 Open Questions for MEP-41

  1. Should MEP-41 directly quote the ONCD report’s “memory-safe languages are the most effective intervention” sentence as its motivating claim?
  2. Should MEP-41 explicitly classify Mochi as memory-safe-by-construction at the language layer, memory-safe-by-runtime-enforcement at the program-state layer? This is more precise than the ONCD’s binary safe/unsafe framing.
  3. The ONCD’s measurability ask is mostly unanswered by industry. Should Mochi commit to publishing per-release memory-safety metrics as a small contribution to this open problem?
  4. C++ Profiles are positioned as the C++ alternative path. Should MEP-41 briefly contrast Mochi’s runtime-enforced safety with the static-analysis-augmented-C++ direction Profiles represents?
  5. The ONCD report does not name Go, Java, Python, or JavaScript — only Rust as the safe-language example. Should MEP-41 note that Mochi is more in the Go / Java / Python family (runtime-enforced) than in the Rust family (compile-time-enforced)? Honest framing matters here.