Memory-Safe Computing Transition

Established Memory safety is the property that a program cannot read or write memory it does not own. Languages that lack it — principally C and C++, which still carry most operating systems, browsers, embedded controllers, and industrial software — permit two families of defect: spatial errors (out-of-bounds reads and writes, buffer overflows) and temporal errors (use-after-free, double free, dangling pointers). These are not exotic. The Morris worm exploited one in 1988; Heartbleed in 2014 and the BLASTPASS iPhone exploit chain in 2023 exploited the same class. The defect class is 35+ years old and has resisted every generation of testing, training, and code review.

Established Across every major C/C++ codebase that has published the number, roughly 70% of serious security vulnerabilities are memory-safety failures. Microsoft reported the figure for its CVEs across 2006–2018; the Chromium project reports it for 912 high- or critical-severity bugs since 2015; a 2019 study found 66–71% for Apple's iOS 12 and macOS Mojave; Google Project Zero found 75% of in-the-wild zero-day exploit chains rested on memory corruption. Few empirical regularities in software engineering replicate this well across independent vendors.

Established The fix is also old: languages that enforce memory safety at compile time or run time eliminate the class rather than mitigating instances of it. Java, C#, Go, Python, Swift, and Ada have long occupied most application niches; Rust matters because it extends the guarantee into the systems niche — kernels, drivers, codecs, cryptography — without a garbage collector, which is why it is the language named in nearly every government roadmap.

Frontier What is new, and what this brief treats as its subject, is that memory safety has become an infrastructure transition rather than a language argument. Since 2022 the transition has acquired the apparatus such transitions need: a measured natural experiment at billion-device scale (Android), state guidance with named agencies on three continents, a binding statute (the EU Cyber Resilience Act), provenance mandates (software bills of materials), a defence research programme for automated migration (DARPA's TRACTOR), and a hardware research path (CHERI). The brief's question is not whether memory-safe languages work — that is measured — but whether institutions can finish a transition whose legacy tail is billions of lines of code embedded in machines with 20–40 year service lives.

Established The baseline regularity is unusually well replicated. Microsoft's Security Response Center reported in 2019 that about 70% of the CVEs it had assigned since 2006 were memory-safety issues, a share that had been stable for twelve years. The Chromium security team reports that around 70% of its high-severity security bugs are memory-unsafety problems, half of them use-after-free, in a dataset of 912 high- or critical-severity bugs affecting the stable channel since 2015. The December 2023 joint guide The Case for Memory Safe Roadmaps — sealed by CISA, NSA, FBI and the cyber agencies of Australia, Canada, the UK and New Zealand — adds that 32 of 34 critical or high bugs in a Mozilla sample were memory-safety issues and that 67% of zero-day vulnerabilities exploited in the wild in 2021 were in this class.

Established Android is the transition's natural experiment, and it is the strongest causal evidence in the field. In 2019 Android shipped 223 memory-safety vulnerabilities, 76% of its total; Google then required no new project in C/C++ where Rust, Java or Kotlin could serve, while deliberately leaving existing code in place. By 2022 the annual count had fallen to 85 and the share to 35%; Android 13 was the first release in which most new code was memory-safe, with Rust at roughly 21% of new native code. Through the end of 2022, the roughly 1.5 million lines of Rust then in the Android Open Source Project — in security-critical components including Keystore2, the ultra-wideband stack and DNS-over-HTTP3 — had zero memory-safety vulnerabilities discovered.

Established The curve has kept falling: 24% of Android vulnerabilities in 2024, and below 20% in 2025 — the first time in the platform's history. Google's September 2024 analysis put the industry norm near 70%, making Android the only large consumer platform measured well below it. The claim rests on the vendor's own vulnerability accounting, but the direction is corroborated by the composition of published Android security bulletins and has not been seriously disputed.

Frontier Google's density and productivity comparisons are more striking and less independently checkable (vendor figures throughout). With about 5 million lines of Rust in the platform by 2025, Google reports approximately 0.2 memory-safety vulnerabilities per million lines of Rust — based on a single pre-release find — against a historical C/C++ rate near 1,000 per million lines, and describes this as a 1000× density reduction. The comparison sets young, heavily reviewed Rust against decades of accumulated C++ history, so the true multiplier is unsettled; even a 10–100× reading would be transformative. On engineering-velocity metrics the same 2025 report says Rust changes in Android need about 20% fewer revisions than C++ changes, spend about 25% less time in review, and for medium and large changes are rolled back about 4× less often; in the third quarter of 2025, net new Rust code in first-party Android development exceeded net new C++ for the first time, and Android's 6.12-based kernel shipped its first production Rust driver.

Established The mechanism that makes a new-code-first policy work is the exponential decay of vulnerabilities in aging code. Google's 2024 analysis, building on published vulnerability-lifetime studies, reports that five-year-old code has a 3.4× (study lifetimes) to 7.4× (lifetimes observed in Android and Chromium) lower vulnerability density than new code, with the average vulnerability lifetime modelled around 2.5 years. Because codebases roughly double every six years, switching only new development to safe languages drives the vulnerability share down on its own as the unsafe stock matures — which is why Android's share fell from 76% to below 20% without a rewrite campaign. This is the single most policy-relevant empirical result in the field: the expensive thing everyone assumed necessary (rewriting the world) is not what produced the measured decline.

Established Where no systematic new-code policy exists, the share falls slowly or not at all. The June 2025 NSA/CISA cybersecurity information sheet Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development notes Microsoft's memory-safety share declined from about 70% of CVEs in 2016 to roughly 50% by 2023 — real progress via C# adoption, sandboxing and compiler hardening, but a visibly shallower slope than Android's.

Established The exposure census is equally concrete. A June 2024 joint report by CISA, the FBI and international partners examined 172 projects underpinning critical infrastructure: 52% contain memory-unsafe code, 55% of their total lines are in memory-unsafe languages, and the largest projects skew worse — the Linux kernel measured at 95% memory-unsafe lines, Chromium at 51%. Even nominally memory-safe projects (Ansible, Home Assistant) inherit unsafe code through cryptography, compression and graphics dependencies. The unsafe substrate is not an edge case; it is the load-bearing layer.

Frontier Aggregate CVE composition may be starting to move, though attribution is contested. In the 2024 CWE Top 25 — computed from 31,770 CVE records between June 2023 and June 2024 — out-of-bounds write lost the #1 rank it had held for three years, displaced by cross-site scripting. Whether that reflects genuine decline in memory-safety exploitability, a boom in reported web vulnerabilities, or changes in CVE reporting practice cannot be separated in the public data; the honest statement is that the aggregate signal is suggestive and unproven.

Established The policy record now matches the technical one in specificity. The February 2024 report of the White House Office of the National Cyber Director, Back to the Building Blocks, endorsed memory-safe languages, hardware protections (memory tagging and CHERI), and formal methods, paired with a research agenda on measurable software quality; its space-systems case study conceded that Rust has not yet been proven in space systems and called for toolchain, workforce and flight-heritage work. The December 2023 roadmaps guide asks manufacturers to publish dated, phased memory-safety roadmaps with named executives, dependency plans and CWE-classified CVE reporting. The June 2025 information sheet carried the same programme into the current US administration, recommending memory-safe languages for all new code and modular migration for legacy systems.

Frontier Does the Android result generalise beyond Google? The best-measured curve comes from one firm with unusual engineering economics: a common build system, an internal Rust ecosystem, and the ability to mandate policy across a whole platform. No second large vendor has published a comparable time series of vulnerability share against safe-language share of new code. Until one does — Microsoft and Apple both could from data they already hold — the transferability of the steep Android slope to ordinary enterprises is an inference, not a measurement.

Frontier Does removing the vulnerability class raise the attacker's total cost, or only move the attack? Memory corruption has dominated in-the-wild exploitation (75% of Project Zero's tracked zero-days) because it yields the strongest primitive: arbitrary code execution. Attackers displaced from it must pay more per capability or shift to logic flaws, identity attacks and supply-chain compromise, which yield different and often weaker primitives. The 2024 CWE reshuffle toward cross-site scripting is consistent with displacement, but no published study yet measures exploit-development cost before and after a platform's memory-safety transition. That measurement — feasible from exploit-broker price lists and zero-day telemetry — is the field's missing dependent variable.

Frontier How safe is the boundary? Every realistic path runs through decades of mixed codebases, and the foreign-function interface between Rust and C/C++ is a place where undefined behaviour can re-enter. Google funded the Rust Foundation with $1,000,000 in 2024 specifically for C++ interoperability, and the June 2025 NSA/CISA sheet devotes most of its practical guidance to hybrid-codebase hygiene: data marshalling, robust inter-language APIs, and isolating high-risk modules. Whether interop layers can be made sound in practice, not just careful, is an open research question.

Frontier Can translation be automated at scale? DARPA's TRACTOR (Translating All C to Rust) programme combines static and dynamic program analysis with large language models to convert legacy C into Rust of the quality a skilled Rust developer would produce, with MIT Lincoln Laboratory as independent evaluator. Early benchmark batteries deliberately cover only basic C features — clear pointer lifetimes, no dynamic allocation — so the hard questions (aliasing-heavy code, hand-rolled allocators, idiomatic versus transliterated output) remain open.

Frontier Is there a hardware shortcut for the code that will never be rewritten? CHERI capability architectures make pointer validity a hardware invariant, protecting even C code recompiled for the platform; a Microsoft Security Response Center analysis in 2020 estimated CHERI would have deterministically mitigated at least two thirds of a year's memory-safety CVEs (cited by name; not re-verified here). The UK's Digital Security by Design programme built the Arm Morello prototype and ran demonstrators from 2019 to 2025, but the programme has ended and no commodity CHERI part has shipped. Arm's Memory Tagging Extension ships in phones today, yet is probabilistic and selectively enabled. The hardware path is real, unpriced, and currently ownerless at commodity scale.

Speculative Formal methods may eventually retire the residual. The ONCD report treats sound static analysis, model checking and assertion-based testing as complements that could certify what languages cannot express, including the roughly 4% of Android's Rust that sits inside unsafe blocks. Verified components exist (seL4, verified TLS stacks); verifying whole consumer stacks remains beyond current tooling by orders of magnitude.

Established The binding constraint is the legacy tail, and it is measured in billions of lines. The critical-infrastructure census puts 55% of lines in 172 foundational projects in unsafe languages, with the Linux kernel at 95%; beyond open source sit proprietary industrial controllers, avionics, medical devices and telecoms equipment written in C against real-time constraints, certified as-is, and deployed in hardware with 20–40 year service lives. New-code policy does nothing for a pipeline controller that will receive no new code.

Established Manual rewriting does not price out at civilisation scale. This is precisely why DARPA funds TRACTOR: the agency's premise is that voluntary hand-migration of legacy C is too slow and too expensive to matter at the scale of the installed base. The rav1d project — a Rust port of the dav1d AV1 decoder — illustrates the grind even for a single well-funded component: after professional porting, a residual performance gap against the C original prompted a $20,000 optimisation bounty in May 2025.

Established Rewrites import a different defect class rather than none. Ubuntu 25.10 shipped Rust implementations of sudo and the GNU coreutils as defaults in October 2025; within weeks a Rust coreutils date-parsing bug briefly broke the distribution's automatic-update mechanism, and two sudo-rs vulnerabilities (one low, one moderate severity) were disclosed and patched in November 2025. The project lead noted neither was memory-safety related — they were logic and compatibility errors, exactly what the theory predicts a rewrite risks. The transition's honest cost accounting includes a transient reliability dip during replacement.

Frontier Toolchain qualification gates the safety-critical niches. Aviation, automotive and space software must be built with qualified toolchains under regimes such as DO-178C and ISO 26262; qualified Rust toolchains have begun to appear commercially (the Ferrocene effort), but the ONCD report's space case study is blunt that Rust lacks flight heritage, deterministic-timing track record and trained personnel in those domains. Certification regimes move at the pace of the certifiers, not of the language.

Established The maintained-commons bottleneck is institutional, not technical. The memory-safe replacements for foundational internet plumbing — Rustls for TLS, ntpd-rs for time (deployed at Let's Encrypt since June 2024), sudo-rs, Hickory DNS — are carried by a thin funding layer: roughly $1 million from AWS and $1.5 million from Germany's Sovereign Tech Fund for Rustls, with long-term stewardship parked in small foundations such as Trifecta Tech. Fragile funding for load-bearing replacements is a single point of failure the roadmaps do not price.

Established Workforce is a decade-scale constraint. The C/C++ workforce is orders of magnitude larger than the Rust workforce in the embedded and OT sectors where the unsafe stock is concentrated, and the NSA/CISA sheet concedes adoption requires up-front investment in training, tooling and refactoring that only pays back over years. Android's counter-evidence — faster reviews and fewer rollbacks once teams are through the learning curve — is from an elite engineering organisation.

Frontier Provenance tooling is behind its mandate. The 2021 NTIA SBOM minimum elements proved too loose for automation; CISA's July 2026 revision had to add component hashes, licences, generating-tool identity and generation context precisely because real-world SBOMs were too inconsistent to drive automated vulnerability matching. An SBOM regime that cannot say which binaries contain which unsafe components cannot measure the transition it is supposed to govern.

Established The transition consumes results from at least five research lines it does not itself produce. First, program-analysis and machine-learning research for translation: TRACTOR's bet is that LLMs constrained by static and dynamic analysis can produce idiomatic, semantics-preserving Rust; that requires advances in alias analysis, lifetime inference and translation validation that are active research, not stock tooling.

Frontier Second, soundness results for language interoperation. Mixed Rust/C++ systems need formal treatment of what guarantees survive the boundary; without it, hybrid codebases carry an unquantified residual risk that current guidance manages by checklist rather than by proof.

Frontier Third, capability-hardware systems research. CHERI needs compilers, operating systems, allocator designs and performance engineering to bring its overheads within commodity tolerance; the Digital Security by Design programme (about £83.5 million public, £270 million recognised industry co-investment, 2019–2025, programme's own figures) built the prototype layer but ended before productisation.

Established Fourth, vulnerability-lifetime empirics. The exponential-decay result that justifies new-code-first policy rests on a small number of studies plus two vendors' internal data; replication across other codebases, and public release of the underlying distributions, would harden the policy's foundation considerably.

Frontier Fifth, the economics of software liability and security metrics. The ONCD report's second half is an unanswered research agenda: no accepted metric yet exists by which a buyer can price the security quality of software, which is why procurement leverage currently runs on attestations and pledges rather than measurement. Until metrics exist, market incentives cannot lock in what regulation starts.

The field is unusually rich in tests that are already running; the discipline is to say which would most change the assessment.

Frontier The decisive test is already running: the TRACTOR evaluation of whether automated translation can turn real C codebases into Rust that maintainers would accept without a full manual rewrite. MIT Lincoln Laboratory scores performer output against benchmark batteries released every six months, and a Round 1 evaluation report has been published. The batteries escalate from basic C (clear pointer lifetimes, no dynamic allocation) through milestone projects including a Perlin-noise library and the SPHINCS cryptographic library, scored on functional correctness, competitive performance and maintainable code quality. This is decisive because it is the only lever that changes the cost curve of the legacy tail: if translation works on million-line codebases with realistic pointer use, the billions of unsafe lines become a finite engineering bill; if it plateaus at transliterated, unsafe-block-riddled output on toy features, the tail persists for decades and the transition remains a new-code story.

Established The Android natural experiment continues and now tests the decay model's floor. The share is below 20% and the theory predicts continued decline as the C/C++ stock ages; the next five years of Android bulletins test whether the curve approaches the old-code floor or stalls, and Google's rollback, review-latency and density figures invite independent replication from the public AOSP repository and bulletin record.

Frontier A second vendor curve is the generalisation test nobody has published. Microsoft (about 50% share in 2023) and Apple hold the data to replicate the Android analysis; either publishing vulnerability share against safe-language share of new code would convert the field's central inference into a measurement. Absent that, the Ubuntu experiment — Rust sudo and coreutils default since 25.10, targeted at the 26.04 LTS — provides a distribution-scale test of whether the defect profile of replaced components actually shifts from memory corruption to shallower logic bugs, as the sudo-rs disclosures so far suggest.

Frontier The displacement measurement: track in-the-wild exploitation, not CVE counts. If memory safety works where it matters, the mix of exploited-in-the-wild zero-days (Project Zero's tracked series) should tilt away from memory corruption on transitioned platforms, and exploit prices for those platforms should rise. A published before/after exploitation-cost study for Android would settle whether the class removal buys security or merely reshuffles taxonomy.

Speculative The hardware demonstration would be a commodity CHERI deployment in one procurement domain. A national buyer specifying capability hardware for, say, industrial gateways — with published incident and performance data — would test whether the two-thirds deterministic-mitigation estimate survives contact with production workloads. With Digital Security by Design concluded, no such deployment is currently scheduled.

Established The proven playbook is new-code-first with targeted replacement, not rewriting. Android's sequence — mandate safe languages for new components, leave old code to age, replace only components that are high-risk and freshly touched — is now codified in the NSA/CISA guidance: write new features in memory-safe languages; decompose legacy monoliths into modules; migrate first the network-facing parsers, codecs, cryptography and privilege boundaries where attacker value concentrates.

Established Hybrid-codebase engineering is the transition's daily work. That means maintained FFI layers and binding generators, data marshalling that neither copies excessively nor aliases unsoundly, build systems that compile two toolchains reproducibly, and test harnesses that exercise the boundary. Google's interoperability grant and the Rust-for-Linux effort (Rust merged into the kernel in October 2022; first production Android driver in the 6.12 kernel) are the reference implementations of this plumbing.

Established The C++ stock gets hardening, not absolution. For code that will not be migrated, the deployed toolkit is compiler-inserted bounds checking, hardened standard-library allocators, pointer-integrity mitigations, sandboxing, and Arm MTE where silicon supports it; Chromium's published strategy spans exactly this spectrum from safer C++ libraries to Rust admission. These measures reduce exploitability at single-digit-percent CPU cost but are mitigations with bypass histories, which is why the guidance treats them as bridges rather than destinations.

Frontier Provenance must become a build artifact, not a compliance document. The 2026 SBOM minimum elements — hashes, licences, tool identity, generation context — only pay off if SBOMs are generated in CI, signed, and linked to vulnerability data through VEX and CSAF so that a buyer can ask the automatable question: which of my deployed binaries contain memory-unsafe components with known CVE classes? That query is the measurable-removal instrument for the whole transition, and today it runs reliably almost nowhere.

Frontier Safety-critical niches need qualified toolchains and flight heritage before language policy can bind. Deterministic timing without garbage collection, kernel-level access, certified compilers and trained staff are the ONCD space study's checklist; until those exist per domain, procurement language can require roadmaps but not conversions.

Established This transition is the software face of a broader measurement problem in infrastructure. Infrastructure resilience argues that resilience claims are empty until failure and recovery are measured as distributions; memory safety is the rare security domain that already has its distribution — vulnerability share by class, by year, by codebase — which is exactly why it can be governed as an engineering transition rather than an aspiration.

Established Procurement is the lever, and procurement is state capacity. The instruments this brief describes — attestation regimes, CE marking under the Cyber Resilience Act, roadmap requirements — live or die on the administrative competence examined in future public administration: agencies that cannot parse an SBOM cannot enforce one.

Frontier The systemic-risk framing connects to economic resilience. A memory-unsafe monoculture in foundational libraries is a correlated-failure exposure of the kind economic resilience treats in supply chains: one Heartbleed-class defect propagates through every dependent system simultaneously. Class removal is, in that vocabulary, the elimination of a common-mode failure.

Frontier Automated translation is a live test case for AI-assisted software engineering. TRACTOR's LLM-plus-program-analysis architecture is among the most consequential applications of the code-generation capabilities surveyed in AI-driven productivity; its independent evaluation regime is also a model for how such claims should be scored.

Established The US built the intellectual apparatus and then weakened its own enforcement lever. Executive Order 14028 (May 2021) created the attestation and SBOM machinery; the NTIA published SBOM minimum elements that July; the ONCD report (February 2024) made class removal national strategy; CISA's Secure by Design pledge (May 2024) enrolled hundreds of companies in seven goals, one of which is reducing entire vulnerability classes, explicitly including memory safety with published roadmaps. But the pledge is voluntary, and CISA states it neither enforces nor verifies adherence. Executive Order 14144 (January 2025) would have formalised machine-readable attestations with CISA validation and public results; a June 2025 executive order stripped those provisions — removing the machine-readable attestation regime, the SBOM requirements and centralised validation, while retaining NIST's secure-development-framework updates — and in February 2026 OMB rescinded the Biden-era software-security memoranda in favour of an agency-led, risk-based approach. The net US position in September 2026: strong published guidance, no binding federal mandate.

Established The binding lever is now European. The EU Cyber Resilience Act entered into force on 10 December 2024 and covers essentially all connected hardware and software sold in the single market. Its vulnerability- and incident-reporting obligations apply from 11 September 2026 — as of this brief's writing — and its main secure-by-design obligations from 11 December 2027, enforced through CE marking, national market-surveillance authorities and third-party assessment for higher-risk product classes; the Commission issued implementation guidance in July 2026. The CRA does not mandate memory-safe languages by name, but it is the first statute that makes shipping products with known vulnerability classes a market-access question, which is the enforcement geometry every voluntary roadmap lacks.

Established The UK ran the transition's industrial-policy experiment on hardware. Digital Security by Design invested about £70 million of Industrial Strategy Challenge Fund money plus £13.5 million added later, with £270 million of recognised industry co-investment (programme's own figures), from 2019 to 2025: Arm built the Morello CHERI prototype and demonstrators ran across automotive, telecoms and defence. The programme closed in 2025 with the technology proven at prototype level and no commodity adoption decision — a completed push with no announced successor pull.

Established A small public-goods funding layer keeps the replacement commons alive. Germany's Sovereign Tech Fund and AWS financed Rustls, ntpd-rs and sudo-rs; the Trifecta Tech Foundation now stewards sudo-rs and zlib successors; Fedora and Ubuntu carry the packages into distributions. This is the transition's least glamorous institution and among its most load-bearing: the CRA can require secure products, but somebody must maintain the components manufacturers will reach for.

Frontier What is institutionally missing is a measurement authority. No body publishes the transition's dashboard — safe-language share of new code by sector, memory-safety share of exploited vulnerabilities by platform, SBOM coverage of deployed critical systems. The ONCD metrics agenda named the gap; three years on, the numbers this brief cites still come from vendor blogs and one-off agency censuses rather than an instrumented reporting regime.

Established The transition redistributes cost from victims to producers, which is its ethical point. Memory-unsafety costs currently fall on users — breach victims, ransomed hospitals, surveilled journalists (BLASTPASS was a zero-click exploit against civil society targets) — while the economics of shipping unsafe code fall on no one. Roadmap mandates, CRA liability exposure and procurement conditions move the cost to the actor who can prevent the defect, the standard move of product-safety regulation.

Frontier Who pays is not settled fairly yet. The unsafe commons is maintained by unpaid or thinly funded volunteers; a compliance regime that obliges manufacturers to remediate dependencies could either fund that commons (the Sovereign Tech Fund model) or strip-mine it with demands. Small and medium manufacturers bear CRA compliance costs at a proportionally higher rate than platform giants who already run safe-language programmes — a concentration pressure regulators acknowledge but have not priced.

Frontier Class removal has a dual-use asymmetry. Shrinking the memory-corruption supply raises costs for criminal exploitation and for state offensive stockpiles alike; states that fund the transition are also its largest exploit purchasers. The June 2025 policy retrenchment in the US illustrates that governments weigh this trade-off, though procurement economics rather than offensive equities is the stated rationale.

Speculative Transparency instruments can double as targeting maps. A signed, accurate SBOM of critical infrastructure is also an attacker's component inventory; the 2026 elements' authenticity and access-control work reflects this tension, and the equilibrium between transparency for defenders and exposure to attackers is unresolved.

Frontier This would be the first deliberate retirement of an entire defect class from civilisation's control layer. Software now mediates power grids, payments, medicine and speech; its dominant vulnerability class has been stable for 35 years. Public-health history offers the template the ONCD report reaches for: sanitation did not treat cholera cases, it removed the transmission class. A measured decline from 76% to under 20% on a billion-device platform is evidence that the sanitation move is available to software.

Frontier The century-scale payoff is a floor under trust in automation. Societies about to delegate driving, grid balancing and administrative decisions to software are currently building on a substrate where most serious failures come from one preventable class. Removing it does not make software trustworthy — logic, design and social attacks remain — but it converts the residual risk into classes that are at least domain-specific rather than ambient.

Speculative The counter-scenario is a two-tier world. Wealthy platforms and regulated markets complete the transition while legacy industrial systems, unsupported devices and poorer regions accumulate the unsafe residue — a distribution of exploitability that mirrors other infrastructure inequalities and concentrates attack traffic on those least resourced to absorb it. Nothing in current policy prevents this outcome; the CRA's market-access mechanism helps only where the market is Europe's.

Speculative Language monoculture is the transition's own tail risk. If the systems layer converges on a single language and toolchain, a defect in that toolchain becomes a civilisational common mode; diversity of memory-safe implementations, and hardware backstops like CHERI that do not depend on any language, are the hedge.

These horizons track the measurable-removal question: what share of new code, of deployed critical code, and of exploited vulnerabilities remains memory-unsafe.

• 10 yr: Frontier New-code flip completes across major platforms and distributions: safe languages dominate new systems code at Google-scale vendors, Ubuntu-class distributions and the Linux kernel driver layer; CRA enforcement from December 2027 produces the first market-surveillance actions and the first public compliance data; the TRACTOR verdict lands — either translation scales past basic batteries to real codebases or the programme documents why not; Android-class platforms test the decay floor near or below 10%; a commodity CHERI go/no-go decision becomes unavoidable as MTE-class mitigations hit their bypass limits.
• 25 yr: Speculative The internet-facing attack surface — browsers, TLS, DNS, time, privilege boundaries — is majority memory-safe in deployment, not just in new code; exploited-in-the-wild memory corruption becomes a minority class on transitioned platforms while the embedded and OT tail, on 20–40 year replacement cycles, remains the reservoir; whether a second-generation hardware backstop shipped at commodity scale is the era's main open variable.
• 50 yr: Speculative Memory-unsafe code occupies the position COBOL holds today: economically significant, professionally niche, concentrated in systems too critical or too obscure to replace — and by then either capability hardware or verified translation has bounded even that residue, or the tail persists as the known soft spot of industrial civilisation.
• 100 / 250+ yr: Handwave Claims that the class stays retired assume languages, hardware and institutions co-evolve without reintroducing equivalent defect classes in new substrates — neuromorphic, quantum-adjacent or AI-generated code — which is assertion, not analysis; the honest long-run statement is only that civilisations can retire defect classes they can measure.

• Depends on Nothing on this map blocks it: the transition runs on commodity hardware, existing languages and current institutions, which is precisely why it is tractable. Its pace, though, is conditioned by the administrative capacity to run procurement and market-surveillance regimes examined in future public administration, and its measurement discipline shares the distribution-first standard argued in infrastructure resilience.
• Requires (not on this map) A translation capability that preserves semantics on million-line C codebases, which TRACTOR is testing but nobody yet possesses; procurement rules that make dated memory-safety roadmaps a condition of sale rather than a pledge; commodity silicon that ships CHERI-class capability enforcement for the code that will never be rewritten; a liability or insurance market that prices vulnerability classes so buyers pay for their absence; and funded, permanent maintenance for the memory-safe replacements of foundational libraries, which today rests on a handful of grants.
• Enables A software substrate whose dominant defect class is retired: cheaper assurance for critical-infrastructure operators, a defensible floor for delegating infrastructure control to software, and an existence proof — transferable to other engineering domains — that a civilisation can measurably remove a failure class rather than perpetually patch its instances.
• Adjacent The systemic common-mode-failure framing of economic resilience; the AI code-transformation capabilities of AI-driven productivity, for which TRACTOR's independent scoring is a governance model.

Established “70% of vulnerabilities means fixing memory safety fixes 70% of security.” No. The 70% figure is a share of CVEs in specific memory-unsafe codebases, not of breaches: most real-world incidents run through phishing, credential theft and misconfiguration, which no language fixes. The defensible claim is narrower and still large — memory corruption dominates the highest-severity, remote-code-execution class and 75% of tracked in-the-wild zero-day exploitation.

Established “The transition requires rewriting everything.” The measured record says the opposite: Android's decline from 76% to below 20% came from switching new development while old code aged in place, and the vulnerability-decay data (3.4–7.4× lower density in five-year-old code) explains why. Rewrite-everything is the strawman both sides of the language argument prefer; neither the ONCD report nor the NSA/CISA guidance asks for it.

Established “Rust code has no vulnerabilities.” False, and the honest version matters: sudo-rs shipped logic and compatibility vulnerabilities in November 2025, about 4% of Android's Rust sits in unsafe blocks, and supply-chain and specification bugs are language-independent. The measured claim is class-specific: zero memory-safety vulnerabilities in Android's first 1.5 million Rust lines, and a density on the vendor's figures orders of magnitude below C/C++.

Frontier “C++ can get there with profiles and static analysis, no migration needed.” Genuinely contested. Hardening, bounds-checked libraries and proposed C++ safety profiles measurably reduce exploitability, and Chromium's strategy invests in exactly that for the stock it keeps; but no profile-hardened large C++ codebase has published an Android-style share collapse, sanitisers find bugs rather than prevent classes, and the agencies' 2025 position treats such measures as complements to, not substitutes for, safe languages. The burden of proof currently sits with the C++-only path.

Established “Governments have mandated memory-safe languages.” None has. The US instruments are guidance and a voluntary, unverified pledge — and the 2025–2026 executive actions weakened the attestation regime rather than hardening it; the EU CRA mandates outcomes and reporting, not languages. The gap between the rhetoric of mandate and the reality of exhortation is where this transition could quietly stall.

Frontier “Hardware (CHERI or MTE) will solve it without touching software.” CHERI's two-thirds deterministic-mitigation estimate is real but prototype-bound: no commodity part ships, the UK programme that built Morello ended in 2025, and recompilation plus some porting is still required. MTE ships today but is probabilistic, selectively enabled and already has bypass literature. Hardware is a backstop for the unrewritable tail, not a substitute for the language transition.

Speculative “AI will translate all the C anyway; wait it out.” A coherent hypothesis with early scaffolding and no scale result: TRACTOR's public batteries so far cover deliberately simplified C, and unassisted LLM translation of pointer-heavy code produces plausible-looking Rust whose correctness is exactly what the independent evaluation exists to check. Waiting is a bet on an unproven capability against a measured, available alternative.

Handwave “Attackers will just move on, so the whole effort is pointless.” The displacement premise is likely true and the conclusion does not follow — that is the handwave. Displacement to logic flaws and identity attacks means displacement to generally weaker primitives and higher per-capability cost; whether total harm falls is an open measurement question this brief flags honestly, but “defence is futile because attackers adapt” would, applied consistently, argue against every safety improvement ever made.