CISA wants a body count on your malloc() calls. They're not entirely wrong.

CISA updated its “Memory Safe Roadmaps” guidance this week, this time with teeth: federal procurement can now flag vendors who haven’t published a credible plan to migrate off memory-unsafe languages for new code. The guidance doesn’t ban anything — it’s not a law, it’s a recommendation with procurement implications — but “procurement implications” is the part that makes vendor legal departments start returning CISA’s calls.

About two-thirds of the CVEs classified as remotely exploitable over the past decade trace back to memory unsafety: buffer overflows, use-after-free, out-of-bounds reads, the whole Stevens chapter-one greatest hits. That number is real. Microsoft has cited it internally for years. Google’s Project Zero publishes it repeatedly. NSA put it in a memo. The fact that the federal government finally noticed and started applying procurement pressure is not the worst outcome — it’s roughly correct threat modeling turned into policy, which is more than you can say for most federal security guidance.

But the mandate has problems. Several of them.

The timeline is a fantasy

The roadmaps CISA is requesting ask vendors to commit to memory-safe languages for new code by 2026 and to have a migration plan for existing code by 2027. That second date is where it falls apart.

Existing code. In C. With thirty years of undocumented behavior, implicit contracts between modules that were never written down, and the kind of aliasing assumptions that are technically undefined behavior but happen to work on every production platform the code runs on. You want a migration roadmap for that by 2027? Written by whom? Funded how? Against what test suite? A realistic migration timeline for a medium-sized critical infrastructure codebase is a decade, not two years — and that’s assuming you have the staff, the budget, and the will to test every subtle behavioral difference between the old and new implementation.

What will actually happen: vendors will publish roadmaps. The roadmaps will say “new code in Rust by 2026” (already done or easy), and “existing code migration plan TBD pending resource allocation.” CISA will accept that, check a box, and the CVE numbers will stay roughly the same because the new code is 3% of the attack surface and the old code is the other 97%.

Rust isn’t magic and “memory safe” is not a binary

Rust prevents a specific class of memory bugs — the ones the borrow checker can reason about. It does not prevent logic errors, integer overflows (in release mode, those wrap without panic by default, which is a choice you have to actively think about), time-of-check-time-of-use races in the unsafe blocks you cannot avoid when talking to hardware or FFI, or the class of vulnerabilities that come from doing cryptography wrong regardless of language.

Every meaningful Rust codebase above a toy size has unsafe in it somewhere. Often because it’s calling into a C library that hasn’t been rewritten yet, which means the memory safety guarantee is only as strong as the C bindings — i.e., the exact thing you were trying to get away from. The mandate treats “written in Rust” as equivalent to “memory safe.” It isn’t. It’s better than C. That’s a real improvement. It’s not an invariant.

Go is the other language that shows up in these roadmaps as a memory-safe alternative. Go has a garbage collector, which prevents use-after-free and most buffer overflows, but GC languages have their own failure modes — and in latency-sensitive systems code, “stop the world for 4ms at random” is a correctness issue of a different kind.

What’s actually going to move the needle

The CVE numbers are driven by a relatively small number of high-value targets: browser engines, OS kernels, network stacks, image parsers. These are old, large, and C. Chrome’s ongoing Rust integration, the Linux kernel’s Rust driver support, and efforts like memory-safe rewrites of core TLS libraries are where real progress happens — because they’re the code that faces the hostile input at scale.

Those rewrites are happening, slowly, with real engineering effort. The CISA mandate will accelerate the vendor marketing copy more than the actual rewrites, but it also funds and legitimizes the efforts that are real. That’s worth something.

If you’re running a shop that writes new systems code, you should be writing it in Rust or Go already, mandate or not — not because a federal agency told you to, but because the tools are mature enough now that the safety floor comes for free. The mandate is most correct on this narrow point: choosing to start a new systems project in C in 2026 is a decision you should have to justify, not a default.

The existing-code migration timeline is still a fantasy. Some of that C is going to outlive the people who wrote it, the agencies that mandated its replacement, and possibly the internet protocols it implements.

---

If you want to understand why this class of bug is structurally hard to eliminate — rather than just knowing that CISA says you should — Stevens’ APUE and Kerrisk’s TLPI will give you the mental model that makes the Rust borrow checker feel like an inevitability rather than a compiler nag.