Thursday, October 1, 2026

Memory Safety Roadmap: The 1,000x Case

Here is the rule. Under the Product Security Bad Practices guidance from CISA and the FBI, a maker of software used in critical infrastructure that had no published memory safety roadmap by January 1, 2026 is, in the agencies' own word, "dangerous". The date came and went. Your firewall vendor, your hospital's imaging supplier, the firm behind your water utility's control panels: none of them owed you a thing when it passed.

Circuit board with a padlock on its memory chips, illustrating a memory safety roadmap

The flaw is in the rule. The same document says it "is non-binding" and "imposes no requirement", so the risk of a missing plan sits with you, the customer. It should be compulsory. And the standard objection, that leaving C and C++ is too slow and too costly, no longer survives the data.

Key Takeaways

Yes, a published plan to retire memory bugs should be compulsory, and buyers can enforce one through contracts today.

  • The federal date passed with no penalty, so the risk sits with the customer.
  • Memory-safe code cut Google's largest bug class without slowing releases.
  • Products near end of life are exempt, so ask for support end dates first.
  • Write a dated plan covering network-facing code into your next renewal.

Is CISA's memory safety guidance mandatory?

No, CISA's memory safety guidance is voluntary: the agencies call a missing roadmap dangerous for critical-infrastructure software, but attach no fine and no procurement ban, so a vendor that ignored the January 2026 date faces nothing.

Washington has stayed in that register. A June 2025 NSA and CISA information sheet on memory safe languages (Rust, Go and others that stop code touching memory it does not own) says the agencies "urge organizations to consider whether adopting MSLs is practical for their circumstances." That hands every vendor two exits, "consider" and "practical". A buyer waiting for a federal push is waiting for something the government has said, in writing, it will not do.

Other regulators have been less shy. Europe wrote vulnerability handling into law, down to the 24-hour exploited-vulnerability warning the Cyber Resilience Act demands. Even NIST put calendar years on its post-quantum migration deadlines. Memory safety, the older and better-understood problem, got an adjective.

Is Rust really safer than C++?

Yes, by a margin that ends the argument. A November 2025 Google report, Rust in Android, found its roughly 5 million lines of Rust running at about 0.2 memory-safety vulnerabilities per million lines, against roughly 1,000 in its C and C++, a reduction Google puts at more than 1,000x. That kills the excuse that safer languages just move bugs elsewhere.

But the objection was always about cost: rewriting slows teams, and ship dates pay salaries. Four numbers test that. Google's Android data supplies two, measured on changes of comparable size. MITRE's CWE Top 25, released in December 2025, supplies a count of memory errors among the most dangerous weaknesses. The calendar supplies the last.

Days Past the Federal Date

273 days

Every one at your risk

Code Review Time Saved

25% less

Reviewer hours handed back

Memory Flaws in CWE Top 25

6 of 25

Worst weaknesses a plan retires

Rollback Rate, Rust vs C++

4x lower

Fewer broken releases to undo

Show the rollback figure to a sceptical finance director. A rollback is a release pulled after shipping, usually an outage and a lost weekend. Fewer of those means the cost objection runs backwards.

"

The safer code also broke four times less often. Speed was the excuse, and Google's own releases retired it.

With no regulator compelling a plan, your contract is the only lever left.

What a required memory safety roadmap changes for buyers

Requiring the plan turns a vendor's vague intention into a dated, auditable commitment that covers its riskiest code first, which gives a buyer something to enforce at renewal instead of a hope.

Dimension Optional vs Required What it means for you
💰 Cost of skipping Optional nothing under federal rules
Required a breach you can enforce
❌ The vendor's risk lands on you
⏱ Deadline Optional 1 Jan 2026, already missed
Required a date you set and enforce
⚠️ Only your contract makes it bite
📊 Flaws per 100k Optional about 100 in C or C++
Required about 0.02 in new Rust
✅ New code stops adding the top bug class
🔒 Fix order Optional whatever the vendor picks
Required network, crypto code first
✅ Your exposed surface is fixed soonest
⚖️ Legacy escape Optional every product, forever
Required support ends before 2030
⚠️ Ask each vendor for its end date
🛠 Proof on file Optional a promise on a sales call
Required public, like F5's Feb 2026
✅ You can audit it against releases
🏁 Best suited for Optional tools you retire this decade
Required anything facing the internet
🏁 Default to required for edge vendors

The flaw-rate row is my arithmetic, not Google's: Android's measured densities scaled to a 100,000-line component. At those rates a new C++ service carries latent memory flaws in triple figures, and the Rust version most likely none.

Industry norm Google plots · about 70%. Memory bugs. Android in 2025, after Rust · under 20%. Memory bugs.

This settles whether a plan is worth demanding: following one moved memory bugs from most of the problem to under a fifth of it. Source: Google's Rust in Android report, whose chart marks the upper bar as the industry norm.

Where a compulsory roadmap gets hard

A compulsory plan gets hard in two places: products close to retirement, which the guidance already exempts, and vendors who publish a roadmap with no dates in it, which satisfies the letter while changing nothing.

Do software makers have to stop using C and C++ by 2026?

No. The CISA and FBI guidance asks existing products for a plan, not a rewrite, and only calls new critical-infrastructure product lines in C or C++ dangerous where a memory-safe alternative exists. I'd go further than CISA, or at least put it more bluntly: a roadmap without a year beside each component is a brochure.

The unresolved question, in my opinion, is embedded firmware. A substation controller will not be rewritten, and a plan for it may mean little beyond the next model. Newer guidance shares the gap, such as the NSA's May 2026 advisory on MCP security for AI agents: sound advice, no teeth. Watch for:

  • Goals with no year per component.
  • Memory-safe claims covering only new features.
  • An end-of-support date just inside the exemption.
  • Sandboxing sold as a substitute, not a stopgap.

Check this against each vendor before your next renewal

  • It faces the internet or handles your keys.
  • Its support is not scheduled to end this decade.
  • Its newest features are still written in C or C++.
  • It cannot send a plan with a year per component.

If two of those are true, stop waiting for Washington. This week, email the vendor asking for its published plan and support end date, and tell procurement that renewal now depends on a dated commitment, cryptographic code first. Require it yourself, because nobody else will.

No comments

Post a Comment