The Memory Safety Deadline Already Passed. Your Buyers Just Started Asking About It.

The Date Nobody Marked, and the Questionnaire That Arrived Anyway

In November 2024, CISA and the FBI published Product Security Bad Practices, a short document listing things software manufacturers should stop doing. It covers the predictable items, default passwords, known-exploited vulnerabilities shipped in released products, absent multi-factor authentication. It also contains one item with a date attached: developing new product lines in a memory-unsafe language, for software supporting critical infrastructure or national critical functions, is designated a bad practice unless the manufacturer has published a memory safety roadmap by January 1, 2026.

The guidance was explicitly non-binding. There is no enforcement body, no penalty schedule, no filing. Most engineering organizations reading it in 2024 filed it accordingly, as a signal about direction rather than an obligation with a deadline, and moved on to things that had actual consequences attached.

That was a reasonable read of the regulatory position and a poor read of how these documents propagate. Non-binding federal guidance with a specific date does not stay in the guidance layer. It gets absorbed into procurement, and procurement is binding in the only way that matters commercially. By the first half of 2026, the memory safety question started showing up in enterprise vendor security questionnaires, in supplier assessments referencing the CISA and FBI framing directly, and in the technical annexes attached to renewals for anything touching operational technology, industrial control, medical devices, or public sector infrastructure.

The awkward part is not that teams disagree with memory safety as a goal. Almost nobody does. It is that the question, as it arrives, is not a philosophical one. It reads: provide your published memory safety roadmap, or explain its absence. Engineering leaders who have spent two years quietly agreeing that Rust is probably the right direction discover that agreeing is not an artifact, and that they have nothing to attach to the response.

Why Memory Safety Became the Thing Governments Picked

Of all the classes of software defect a policy agency could have selected, memory safety got singled out because the data behind it is unusually unambiguous. Microsoft's security response engineers reported for years that roughly 70% of the CVEs they assigned traced to memory safety issues. The Chromium project reported a near-identical proportion for its serious security bugs. When two of the largest and best-resourced security programs in the industry independently land on the same number for the same defect class, the case stops being a matter of taste.

It is also a defect class with a demonstrated fix, which is rarer than it sounds. Google's Android program is the most-cited proof point precisely because it ran long enough to produce a trend rather than an anecdote. Memory safety defects fell from 76% of Android's vulnerabilities in 2019 to 24% by 2024, and in 2025 dropped below 20% for the first time. In absolute terms the count went from 223 memory safety vulnerabilities in 2019 to fewer than 50 in 2024.

The interesting detail in Google's own write-up is not the security number. It is the delivery number. Rust changes in Android showed roughly a 4x lower rollback rate than the equivalent C and C++ changes, spent about 25% less time in code review, and required around 20% fewer revisions. Memory safety vulnerability density in the Rust code came out around three orders of magnitude below the C and C++ code. The argument that memory-safe languages trade velocity for safety did not survive contact with a codebase that size.

The other driver is geopolitical rather than technical. The Case for Memory Safe Roadmaps, published by CISA, the NSA, the FBI and the cybersecurity authorities of Australia, Canada, the UK and New Zealand, frames the issue around state actors positioning inside critical infrastructure. Campaigns of that kind depend heavily on the memory corruption primitives that memory-safe languages structurally eliminate. That framing is why this guidance arrived with multiple national seals on it, and why it carries weight in procurement well beyond its formal legal status.

What a Credible Roadmap Actually Contains

The word roadmap invites the wrong artifact. Teams reach for a slide with three horizontal arrows and a 2029 endpoint, and that document fails the first serious question a buyer's technical advisor asks, which is always some version of: how much memory-unsafe code do you have, and where is it?

A roadmap that survives review has four parts. The first is an inventory: how much C and C++ you actually ship, which components it constitutes, and which of those are network-facing, parse untrusted input, handle cryptography, or run with elevated privilege. This sounds trivial and is usually the part that takes longest, because most organizations have never counted, and the answer includes vendored dependencies, build tooling, and code inherited through acquisitions that nobody has opened in years.

The second is a commitment on new development. This is the highest-leverage and cheapest element, and it is what Android's numbers actually demonstrate: they did not rewrite the existing C and C++, they stopped adding to it. New code in memory-safe languages, with a defined and narrow exception process, bends the curve without touching a line of the legacy base. Any roadmap that does not contain this commitment is not credible, because it describes a plan to shrink a surface that is still growing.

The third is prioritized migration, expressed as components and dates rather than percentages of a codebase. Priority follows exposure: network-facing parsers first, then anything deserializing untrusted input, then cryptographic implementations and privileged helpers. The fourth is the honest part, which is what you are not migrating and why, along with the compensating controls, fuzzing coverage, sanitizer builds in CI, hardened allocators, hardware mitigations where the platform supports them. Buyers respond considerably better to a roadmap that scopes itself out of 60% of the codebase with stated reasoning than to one that implies everything will be Rust eventually.

The AI Complication: The Surface Is Growing Faster Than You Are Shrinking It

There is a timing problem underneath all of this that the 2024 guidance did not anticipate. The volume of new C and C++ entering codebases is rising, because AI coding assistants generate it on request and generate it fast, and the security profile of what they produce is not good.

Veracode's testing across more than 100 models found that 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability, and, more usefully for planning purposes, that the pass rate stayed essentially flat at around 55% from 2025 through early 2026 despite a full cycle of model releases. Academic work assessing state-of-the-art models generating C specifically has found vulnerability rates well above the aggregate, with memory-management defects clustering in exactly the C and C++ output that memory safety policy is aimed at. Prompts optimizing for efficiency correlate with memory safety issues in a substantial share of generations, which is an unfortunate interaction given that efficiency is precisely why teams are still writing C.

The volume effect compounds the rate effect. Apiiro's analysis of a Fortune 50 environment between December 2024 and June 2025 found AI-assisted developers committing at three to four times the rate of their peers, with monthly security findings rising from roughly 1,000 to over 10,000, and privilege escalation findings up 322%. And the defects are starting to surface publicly: the Cloud Security Alliance's 2026 research note tracks CVEs attributed to AI tooling going from 6 in January 2026 to 15 in February to 35 in March, with researchers estimating the true figure at five to ten times the confirmed count.

For a team with a memory safety roadmap, this changes the sequencing. The new-development commitment is not a slow-burn cultural item to be handled after the inventory is complete. It is the urgent one, because an assistant that will cheerfully produce a new C parser on request is adding to the exact surface you have just promised a customer you are reducing. Whatever policy you set has to be enforced where the code enters, in review and in CI, not in a document. We have written separately about the broader shape of this problem in comprehension debt, and memory safety is where it becomes legible to regulators.

The Translation Fantasy, and What DARPA's Answer Tells You

The obvious thought, once you accept that AI writes C badly, is that AI might at least translate it. Point a capable model at the legacy base, emit Rust, ship the roadmap. It is a genuinely reasonable instinct, and the fact that DARPA is spending real money on it should tell you both that it is worth pursuing and that it is not a weekend project.

TRACTOR, DARPA's Translating All C to Rust program, exists specifically to automate this, combining large language models with static and dynamic analysis, with evaluation run by a team at MIT Lincoln Laboratory. Its stated bar is output of the quality and style a skilled Rust developer would produce, which is the correct bar and a demanding one. Academic teams working under it, including a group spanning Illinois, Wisconsin-Madison, Berkeley and Edinburgh, are pairing formal verification with LLM translation rather than trusting the models alone. The program is scoped on a multi-year horizon and explicitly designed around the assumption that models will be substantially better in four years than they are today.

The reason it is hard is worth understanding, because it determines what you can and cannot promise in a roadmap. Mechanical C-to-Rust translation produces Rust that compiles and is not memory-safe in any meaningful sense, because the pointer patterns of the original translate into unsafe blocks and raw pointers. The safety in Rust comes from the ownership model, and ownership is a design decision that the C source does not encode. Deciding who owns a buffer, what its lifetime is, and which aliasing is permitted is precisely the engineering judgment that was never written down. On top of that sit FFI boundaries, build system integration, and the requirement that behavior stay bit-for-bit identical for code with real-world callers.

What this means practically is that AI is a genuine accelerator on the mechanical 70% of the work, the boilerplate, the struct definitions, the test scaffolding, the first-pass translation that a senior engineer then reshapes, and close to useless on the 30% that determines whether the result is actually safe. That ratio is good news for cost. It is not a reason to promise a buyer that the codebase converts itself.

Where Migration Pays, and Where It Does Not

The failure mode here is the full rewrite, and it fails for reasons that have nothing to do with Rust. Rewrites of large working systems have historically run 12 to 24 months, cost seven figures, and failed at rates around 70%, and the failure is organizational rather than technical: the rewrite runs alongside a product that keeps evolving, the target keeps moving, and eventually someone cancels it. Nothing about memory safety changes that arithmetic.

The prioritization that does work follows exposure rather than volume. Code that parses untrusted input from a network is where memory safety defects become remote code execution, and it is usually a small fraction of a codebase. Deserialization paths, media and document parsers, protocol implementations, cryptographic primitives, and privileged helper processes make up the tier that justifies migration on security grounds alone. A pure computation kernel with no external input, running in-process, with no attack surface, may never justify the work, and saying so in the roadmap is a sign of engineering judgment rather than a gap.

Incremental interop is what makes this tractable. Rust interoperates with C through FFI well enough that a single component can be replaced behind a stable interface while the rest of the system stays exactly as it is. The pattern that works is one component at a time, differential-tested against the original implementation, fuzzed at the boundary, shipped behind a flag, with the C version retained until the replacement has run in production long enough to be trusted. This is unglamorous and it is why Android's numbers moved: not a rewrite, a sustained sequence of bounded replacements plus a hard rule about new code.

There is a sequencing argument for doing this now rather than in 2028, which is that it stacks with work many European teams already have scheduled. Migration of network-facing parsers overlaps with Cyber Resilience Act readiness, since the CRA's secure-by-design obligations and SBOM requirements demand the same component inventory a memory safety roadmap starts with. It also overlaps with post-quantum cryptography migration, which touches the same cryptographic implementations. Three compliance programs, one inventory, one set of components, one team. Run separately, they cost roughly three times as much.

The Talent Problem Is the Real Constraint

Every roadmap eventually collides with the same question: who does the work. And this is where the memory safety push runs into a genuine market constraint rather than a budgeting one.

Rust adoption is real and no longer speculative. Enterprise use reached 48.8% in the 2025 State of Rust survey, up from 38.7% in 2023, and roughly half of surveyed companies now run Rust in production. AWS has run Firecracker in production since 2018, Microsoft ships Rust in Windows kernel components, and the Linux kernel accepts it. But the developer base is around 2.3 million against a global population of software engineers an order of magnitude larger, and the subset with the specific experience this work needs, systems-level Rust, unsafe code auditing, FFI boundaries with existing C, is far smaller than that.

Pricing reflects it. Rust developer salaries average around $130,000 with senior systems engineers in the US at $170,000 to $300,000, and systems-level Rust roles command a 15 to 25% premium over application Rust at equivalent seniority, precisely because the pool is smaller and the experience takes longer to accumulate. Postings have more than doubled in two years. If your plan is to hire a permanent Rust team in London, Munich or the Bay Area for a migration that has an end date, you are competing on price for scarce people to do finite work, which is the worst position in the hiring market.

The shape of the work makes permanent hiring the wrong instrument anyway. A memory safety programme has a beginning and an end. The inventory takes weeks. The new-code policy and CI enforcement take weeks. The component migrations run in a defined sequence over two to four quarters depending on scope. After that, the ongoing requirement is a much smaller maintenance load that your existing team can absorb, having learned the patterns. Hiring permanently for a peak that resolves in eighteen months creates a different problem to solve later.

Running It as a Parallel Track

The teams that get through this without damaging their roadmap all structure it the same way: as a separate track with its own people, its own scope, and its own definition of done, running alongside product delivery rather than inside it. The instinct to hand memory safety work to the team that owns the component is understandable and usually wrong, because those are the same engineers carrying the feature commitments, and in any contest between a customer-visible release and a migration with no external deadline, the migration loses every sprint until it is quietly abandoned.

A workable first ninety days looks concrete. Weeks one to three: inventory every component containing memory-unsafe code, classify by exposure, and produce the count. Weeks three to six: land the new-development policy, with CI enforcement so it is a build failure rather than a guideline, plus sanitizer builds and fuzzing on the top-exposure components so you have compensating controls to point at immediately. Weeks six to twelve: migrate one component end to end, the highest-exposure parser, as a reference implementation that establishes the pattern, the review standards, the differential test harness, and the actual cost per component. That last number is what turns the roadmap from aspiration into a plan, because everything after it is estimated against a real data point rather than a guess.

At StepTo we have run senior engineering teams out of Serbia since 2014, and this is a familiar shape: bounded, senior, specialist work that a client's own team should not be pulled onto. A dedicated development team can own the inventory, the reference migration, the fuzzing and sanitizer infrastructure, and the roadmap document itself, working against your components while your engineers keep shipping what they committed to. Engineers are assigned by name and stay with the codebase, which matters disproportionately here, because most of the difficulty is reconstructing the ownership and lifetime assumptions that the original C never recorded, and that understanding takes weeks to build and one staff rotation to lose. Where a team already has the people and needs a specific capability added rather than a separate group, staff augmentation with named senior engineers is usually the faster route in.

The nearshore argument here is not primarily about rates, although a senior systems engineer in Belgrade against a US systems-Rust premium is a material difference over four quarters. It is that this work is unusually conversation-dependent. Deciding the ownership model for a buffer that three subsystems touch is not a ticket; it is a whiteboard session with the person who has maintained that code for six years. Four or more hours of overlap with Western European working hours is the difference between resolving that in an afternoon and losing a day per decision to an overnight handoff. The same applies to the backend and service-layer work around the migrated components and to the build, CI and fuzzing infrastructure that has to exist before any of it is verifiable.

One last piece worth budgeting: publish the roadmap. Not internally, publicly, or at least in a form you can hand to a customer without redrafting it. The entire premise of the CISA guidance is transparency to buyers, and a roadmap that exists only in a Confluence space does not answer the questionnaire. It is also the artifact that shows up later in acquisition diligence, where the absence of one is read the same way the absence of an SBOM now is, as evidence that security was managed reactively. We cover the adjacent version of that problem in our note on technical diligence on AI-generated code.