Memory Safe Language Adoption in 2026: A Data Scorecard

Memory safe language adoption in 2026 is real where large owners pushed it: Google says memory safety bugs fell below 20 percent of Android vulnerabilities in 2025, and Linux maintainers ended the kernel's Rust experiment in December 2025. Everywhere else, C and C++ still dominate the code you ship, so hardening and fast patching remain essential.

This scorecard puts four kinds of evidence side by side: what governments asked for, what the biggest codebases did, what developers report, and what weakness data shows. Every figure carries its date and source, and where numbers are soft or disputed, we say so.

Key takeaways

• Policy is settled and its deadline has passed. CISA's Product Security Bad Practices guidance (v2.0, January 2025) asked vendors to publish a memory safety roadmap by the end of 2025. CISA and NSA added adoption guidance in June 2025.
• Android is the strongest public proof. On 13 November 2025 Google reported memory safety bugs below 20 percent of Android vulnerabilities for the first time, with about 5 million lines of Rust in the platform.
• The density estimate is striking but thin. Google estimates about 0.2 memory safety vulnerabilities per million lines of Rust against about 1,000 in historical C and C++, from a single near miss.
• Rust in Linux is permanent, and still small. It supports seven architectures, each with constraints, and remains a small fraction of kernel source.
• Sentiment runs ahead of usage. Rust is 10th in TIOBE for October 2026 at 1.44 percent; C and C++ together hold 20.20 percent. In Stack Overflow's 2025 survey, 14.8 percent used Rust.
• Your exposure is mostly in code you will not rewrite: C and C++ libraries bundled in packages and images. That is a patching problem today.

The scorecard at a glance

Grades are our judgement of outcome and evidence strength, built from the dated figures below.

What did the June 2025 CISA and NSA guidance actually recommend?

CISA published "Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development" with the National Security Agency on 24 June 2025. CISA's summary describes it as a guide to the main obstacles to adopting memory safe languages, practical solutions, and the factors that matter when moving toward more secure development, building on earlier advice about language level protections, library support, tooling and developer training.

In our research the full Cybersecurity Information Sheet names Ada, C#, Delphi and Object Pascal, Go, Java, Python, Ruby, Rust and Swift as memory safe examples, and covers making code in non memory safe languages safer during a transition. The PDF on the Department of Defense media server refused automated access when we wrote this, so treat that list as our reading of the document and check the PDF before citing it in a contract.

The sheet is the third step in a sequence:

The Bad Practices document is the one with teeth. For existing products in memory unsafe languages, it calls a missing roadmap dangerous and asks for a prioritised plan covering priority components such as network facing code and code handling cryptographic operations, published by the end of 2025. Products with an announced end of support before 1 January 2030 are exempt. New product lines for critical infrastructure should use memory safe languages where readily available alternatives exist.

Two details are easy to miss. The guidance is voluntary. And the same list puts memory safety beside SQL injection, command injection, default passwords and shipping components with known exploited or critical vulnerabilities. Several of those are dependency hygiene, not language choice.

We found no authoritative public count of how many vendors met the end of 2025 deadline, and we do not invent one. Our posts on the CISA memory safe languages roadmap and the memory safety roadmap checklist for product teams cover roadmap content in depth.

What share of Android vulnerabilities are memory safety bugs in 2025?

On 13 November 2025, Jeff Vander Stoep of the Android team published "Rust in Android: move fast and fix things". The headline: in 2025, memory safety vulnerabilities fell below 20 percent of Android's total for the first time.

Google calls the 2025 figure preliminary, published before year end, but likely close to final given Android's 90 day patch window. The chart covers 2019 to 2025 and shows the share above the commonly cited 70 percent line in the first three years and below it in the last four. The text does not give exact earlier percentages.

That matters because older Android baselines circulate in different forms (76, 35 and 24 percent are all quoted for different years and scopes). We could not load the text of Google's September 2024 post on the topic, so we cite only the 2025 post. If you need a year by year series, take it from Google's own posts with year and scope beside each number.

The productivity rows answer the common objection that safer code slows delivery. For Google's teams, Rust changes needed fewer revisions, less review time and fewer rollbacks. Google notes the comparison assumes similar change sizes and that Rust's slightly denser functionality favours C++. It speculates the 2023 to 2024 review time gain reflects growing Rust expertise, a hint that the first year of any roadmap is the expensive one.

How solid is Google's Rust versus C and C++ density estimate?

The headline is real; the precision is not. The Rust side comes from exactly one vulnerability: CVE-2025-48530, a linear buffer overflow in CrabbyAVIF, a Rust component. It was fixed before any public release, and Google says the Scudo allocator's guard pages made it deterministically non exploitable. The related Android Security Bulletin is dated 1 August 2025.

A rate built from one event has a very wide uncertainty band. One more bug doubles it. Google itself calls the estimate conservative and rough. What it does support is the order of magnitude: even if the true Rust rate were fifty times higher than 0.2, it would still sit far below 1,000.

On unsafe Rust, Google says it does not know for sure why unsafe Rust appears less buggy than C and C++, and argues that assuming it were equally buggy per line would still overestimate its risk. Count and review your unsafe blocks, but do not treat them as equivalent to a whole C file.

CrabbyAVIF teaches a second lesson: the near miss was harmless because of allocator hardening. A roadmap that drops hardening once code moves to Rust gives up a layer that just proved its value.

What changed for Rust in the Linux kernel in December 2025?

At the annual Maintainers Summit in Tokyo in December 2025, kernel developers agreed Rust is no longer experimental. LWN's 10 December 2025 report by Jonathan Corbet says Rust is now a core part of the kernel and the "experimental" tag will be removed. When readers misread the headline, Corbet clarified that "the experiment is done, and it was a success."

DevClass's 15 December 2025 report adds:

• Miguel Ojeda, who leads Rust for Linux, wrote to the kernel mailing list that Rust is here to stay, while cautioning that this does not mean everything works for every configuration, architecture or toolchain.
• Dave Airlie, the DRM graphics maintainer, said DRM is about a year away from requiring Rust and disallowing C for new drivers.
• Greg Kroah-Hartman said Rust drivers are proving safer than C drivers, with fewer Rust to C interaction problems than expected.
• Android 16 devices on the 6.12 kernel ship the ashmem allocator written in Rust, putting Rust for Linux on millions of devices.
• Per Corbet's summit report, the kernel will stay buildable with the Rust version in the latest Debian stable, and gccrs developers treat building the kernel as a top priority.

The kernel's own documentation shows the practical limits:

rustc relies on LLVM for code generation and bindgen depends on libclang, which limits targets. The quick start guide calls a full LLVM toolchain "the best supported setup at the moment" and GCC builds "very experimental". If you ship embedded Linux on 32 bit x86, big endian Arm or an unlisted architecture, Rust kernel drivers are not an option today, and your kernel plan is still hardening plus fast updates.

How much Rust is actually in the Linux kernel?

Less than the headlines suggest. One trade publication put Rust at roughly 25,000 lines against roughly 34 million lines of C as of April 2025. We could not load that article to verify the count or method, and counts change every release, so treat it as an order of magnitude marker. Even after several fold growth, Rust would remain well under one percent of kernel source.

Measure the release you ship with the commands in the walkthrough below, and count the rust directory and drivers separately: bindings and abstractions exist so drivers can be written in Rust, and are not the same as Rust replacing C driver code. "No longer experimental" is a governance decision. For years to come, almost every kernel vulnerability you patch will still be in C.

What do the other platform owners show?

Chromium's memory safety page reports that about 70 percent of its high severity security bugs are memory safety problems, half of them use after free, based on 912 high or critical bugs affecting Stable since 2015.

Its strategy is broader than rewriting: safer C++ base libraries and checks added to the standard library and Abseil, hardware mitigations such as Arm's Memory Tagging Extension, a custom C++ dialect enforced through LLVM plugins and presubmit checks, and safer languages (Java, Kotlin, JavaScript, Rust, Swift) where they fit. That mix is a realistic model for most companies.

A widely cited 2019 Microsoft security response post also measured memory safety's share of Microsoft CVEs. Its old address now redirects to a blog index, so we do not quote its figure.

How does developer sentiment compare with usage share for Rust?

Developers like Rust far more than they use it. "Admired" and "used" measure different things.

Stack Overflow's survey drew more than 49,000 developers from 177 countries; 31,771 answered the language question. Rust ranked 14th by usage. Rust has topped the survey's "admired" ranking for years, and coverage of the 2025 edition puts its admired score at 72 percent. We could not load the admired chart on the interactive survey page, so we report that as widely reported, not confirmed. Admired measures retention among people who already chose Rust, not a share of all developers.

TIOBE counts search results, so it tracks visibility more than production code. Rust rose from 16th a year earlier to 10th in October 2026. The Rust project's 2024 survey (7,310 completed responses) found the top reason for company use was building relatively correct and bug free software, ahead of performance; 38 percent of respondents use Rust for most of their coding. It is a self selected group of Rust users.

Ranked: CSI memory safe languages and C and C++ by TIOBE rating, October 2026

Each block is roughly one percentage point.

Ruby was outside the top 20 and we did not record its rating, so it is omitted. Python, Java and C# are memory safe in their own code, but their runtimes and many extension modules are C or C++. A Python service still loads native libraries for compression, image parsing, cryptography and XML.

Which memory safety CWEs still rank in the CWE Top 25?

MITRE's 2025 CWE Top 25 keeps memory safety weaknesses near the top, even as cross site scripting, SQL injection and cross site request forgery hold the first three places.

MITRE's ranked table timed out when we fetched it, so these ranks come from MITRE's pages as indexed by search and from trade coverage. Check the 2025 page for out of bounds read and NULL pointer dereference before quoting their positions. The three new buffer overflow entries are partly a mapping effect, as CVE records map to more specific child CWEs, so year over year rank moves are a poor progress measure. Our posts on memory safety in the 2025 CWE Top 25 and how much vulnerability data is memory safety go deeper.

The gap between intent and code

Put the datasets together and three conclusions follow.

First, Android's result came from where new code was written, not from rewriting old code. Net new Rust slightly exceeded C++ in 2025 while a large C and C++ base remained, and memory safety's share of vulnerabilities still fell below 20 percent. That took one of the best resourced engineering organisations years.

Second, most organisations already write much of their application code in memory safe languages such as Java, C#, Go, Python or TypeScript. Their memory unsafe exposure sits in operating system packages, runtimes, native extensions and vendored libraries, where memory corruption CVEs keep landing.

Third, sentiment is not a migration plan. A high admired score says Rust keeps its users. It does not say your vendors rewrote their parsers.

What can teams do for C and C++ code that will not be rewritten?

The CISA and NSA sheet covers making non memory safe code safer, and Chromium shows it at scale. Five buckets:

1. Compiler and linker hardening. Fortified source, stack protectors, stack clash protection, control flow protection, full RELRO with immediate binding, position independent executables. The OpenSSF compiler options hardening guide for C and C++ explains each flag; use it for your toolchain version.
2. Hardened standard library modes. Recent LLVM libc++ releases add bounds checks to containers and views at modest cost. Chromium adds similar checks to its standard library and Abseil.
3. Sanitisers and fuzzing in CI. AddressSanitizer and UndefinedBehaviorSanitizer catch memory errors in tests; fuzz parsers and protocol handlers.
4. Safe subsets. Ban raw pointer arithmetic in new code, require bounds checked views, and enforce rules with static analysis or compiler plugins.
5. Allocator and hardware mitigations. Hardened allocators and, on supported Arm hardware, memory tagging work without finding the bug first. Android's allocator neutralised its one Rust near miss.

A sixth item is about code you did not write: patch the C and C++ you consume. Most memory corruption CVEs in a typical product arrive through a dependency or base image, which makes this supply chain discipline.

Walkthrough: measure your own memory safety baseline

Step 1. Measure the language mix of your repositories

# Lines of C and C++ (source and headers) tracked in git
git ls-files '*.c' '*.h' '*.cc' '*.cpp' '*.cxx' '*.hpp' '*.hh' \
  | xargs wc -l | tail -1

# Lines of Rust
git ls-files '*.rs' | xargs wc -l | tail -1

# Other languages for comparison
for ext in go java kt cs py ts; do
  printf '%s ' "$ext"; git ls-files "*.$ext" | xargs cat 2>/dev/null | wc -l
done

Record totals with the date and commit hash. That is your first scorecard row.

Step 2. Count unsafe Rust

git ls-files '*.rs' | xargs grep -l 'unsafe' | wc -l
git ls-files '*.rs' | xargs grep -c 'unsafe' | awk -F: '{s+=$2} END {print s}'

Google reports about 4 percent of Android's Rust is unsafe. Track your own trend.

Step 3. Measure Rust in the kernel you ship

git clone --depth 1 --branch v6.12 \
  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
cd linux
find . -name '*.rs' -not -path './Documentation/*' | xargs wc -l | tail -1
find . \( -name '*.c' -o -name '*.h' \) | xargs wc -l | tail -1
make LLVM=1 rustavailable

The last command, from the kernel's quick start guide, checks whether your toolchain can build Rust support.

Step 4. Find the C and C++ you did not write

# Shared libraries inside an image
docker run --rm --entrypoint sh your-image:tag -c \
  'find / -xdev \( -name "*.so" -o -name "*.so.*" \) 2>/dev/null | sort'

# SBOM and vulnerability scan of a repository, an image, or an existing SBOM
safeguard scan --dir .
safeguard scan --image your-image:tag
safeguard scan --sbom ./sbom.cdx.json

Results land as JSON under ./output. Filter findings by CWE to see how many are memory corruption classes such as CWE-787, CWE-416, CWE-125, CWE-120, CWE-121 and CWE-122.

Step 5. Add sanitiser and hardening builds

name: sanitizers
on: [pull_request]
jobs:
  asan-ubsan:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - name: Configure
        run: |
          cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug \
            -DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \
            -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer"
      - name: Build
        run: cmake --build build -j
      - name: Test
        env:
          ASAN_OPTIONS: detect_leaks=1:abort_on_error=1
          UBSAN_OPTIONS: halt_on_error=1:print_stacktrace=1
        run: ctest --test-dir build --output-on-failure

# Release hardening; confirm each flag against the OpenSSF guide for your compiler
CFLAGS="-O2 -D_FORTIFY_SOURCE=3 -fstack-protector-strong \
  -fstack-clash-protection -fcf-protection=full -fPIE"
LDFLAGS="-pie -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack"
CXXFLAGS="$CFLAGS -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_FAST"

Step 6. Gate new memory unsafe components

Require memory safe languages for new code that parses untrusted input or faces the network, matching CISA's priority components, and enforce it in review. For dependencies, a policy gate that blocks new components with known critical vulnerabilities stops the backlog growing while the roadmap runs.

How should a memory safety roadmap be measured year over year?

Two rules keep the series honest. Fix which CWEs count as memory safety on day one and never change it mid series, because CWE mapping changes move numbers by themselves. And report every figure with date and scope.

What does memory safety not fix?

Memory safe languages remove one large bug class and leave most of the CWE Top 25 alone. Cross site scripting, SQL injection, cross site request forgery, missing authorisation, path traversal, command injection and unsafe deserialisation all happen in memory safe code.

They do not fix the supply chain either. A Rust or Go service can still pull a vulnerable or compromised dependency, and CISA's Bad Practices list puts shipping vulnerable components right beside the roadmap item. See our Rust memory safety CVE trend analysis and Rust adoption in security critical software.

And they do not fix the boundary. Every memory safe language eventually calls C through a foreign function interface, a system library or the kernel.

How we measured

• Scope. Dated primary evidence on four questions: what governments asked for, what large code owners did, what developers report, and what weakness data shows. Sources: CISA, NSA, Google's Android team, kernel documentation and LWN's summit reporting, Chromium, MITRE, TIOBE, Stack Overflow and the Rust project.
• Dates. Each figure carries its source's date. TIOBE is October 2026; Stack Overflow is the 2025 survey published 29 July 2025; the Rust project figures are the 2024 survey published 13 February 2025. Google's 2025 Android share is preliminary.
• Verification. We fetched each source on 23 October 2026. Where a page could not be loaded (the CISA and NSA PDF, MITRE's ranked table, Stack Overflow's admired chart, a trade article on kernel line counts, a 2019 Microsoft post, Google's September 2024 Android post), we say so beside the figure or leave it out.
• Grades and ranking. Letter grades are our judgement, not a published index. The ranked table uses TIOBE's October 2026 ratings and our reading of the CSI's language list.
• What we did not do. We did not count kernel lines ourselves, compute densities beyond those owners published, or adjust any figure.

Common mistakes

• Quoting "70 percent" as current for everyone. It describes specific code bases and periods; Android is now below 20 percent.
• Treating the 1,000x ratio as precise. It rests on one Rust bug.
• Reading "no longer experimental" as "the kernel is moving to Rust". It is a status change.
• Confusing admired with used. Use usage share for planning.
• Forgetting Java, C#, Go, Python and Swift are memory safe. Exposure often sits in native dependencies instead.
• Roadmaps that cover only first party code. Base images and native extensions ship with your product too.
• Dropping hardening after a rewrite. Allocator hardening neutralised Google's near miss.
• Changing the metric definition mid roadmap. The trend line becomes meaningless.

FAQ

Which languages are memory safe according to CISA and NSA?

Our reading of the June 2025 information sheet is that it names Ada, C#, Delphi and Object Pascal, Go, Java, Python, Ruby, Rust and Swift. C and C++ are the main memory unsafe languages addressed. Check the PDF before citing it formally.

Did CISA set a deadline for memory safety roadmaps?

Yes, a voluntary one. Product Security Bad Practices v2.0 (17 January 2025) recommends publishing a roadmap by the end of 2025, exempting products with announced end of support before 1 January 2030.

What percentage of Android vulnerabilities are memory safety bugs?

Below 20 percent in 2025, the first time, according to Google's 13 November 2025 post. Google calls the figure preliminary.

Is Rust really 1,000 times safer than C++?

Google estimates about 0.2 memory safety vulnerabilities per million lines of Android Rust versus about 1,000 for historical C and C++. The Rust figure comes from one near miss, so only the order of magnitude is reliable.

Is Rust still experimental in the Linux kernel?

No. Maintainers agreed at the December 2025 Maintainers Summit that Rust is permanent. Architecture and toolchain support remain limited.

How much of the Linux kernel is written in Rust?

A small fraction. An unverified April 2025 trade press count put Rust near 25,000 lines against about 34 million lines of C. Measure the release you ship.

Is Rust the most popular programming language in 2026?

No. It is 10th in TIOBE for October 2026 at 1.44 percent, and 14.8 percent of Stack Overflow's 2025 respondents used it. It is highly admired by its users, which is a different measure.

Does switching to a memory safe language fix supply chain risk?

No. Memory safe code still depends on packages that can be vulnerable or compromised, and still links native libraries.

What should we do with C and C++ code we cannot rewrite?

Harden builds, use hardened standard library modes, run sanitisers and fuzzing in CI, enforce safer subsets, use hardened allocators, and patch consumed native libraries quickly.

Fix it without waiting for upstream

A memory safety roadmap runs for years. The memory corruption CVEs in C and C++ libraries you consume today do not have to wait for any rewrite.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Safeguard inventories components, including native libraries in container image layers, and matches them to vulnerability data. It does not analyse C or C++ source for memory safety bugs or replace the hardening, sanitiser and fuzzing work above. Download the apps at safeguard.sh/download and read the CLI docs at docs.safeguard.sh/docs/cli.

See how Safeguard would help

The first demo is a real CLI session: install, open the interactive terminal with safeguard, and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow applies to a native library pinned in a manifest or base image tag.

Click through it at your own pace, or open it full screen.

The second demo sets up the runner on your own machine, approves it with its device code, then scans from the terminal. This is how you would run the walkthrough's image and repository scans on a build machine that can reach your private images.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. Once connected, you can ask about your own findings, such as which projects carry a given native library version.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Google: Rust in Android, move fast and fix things (13 Nov 2025)
• CISA: Memory Safe Languages, Reducing Vulnerabilities in Modern Software Development (24 Jun 2025)
• NSA and CISA CSI PDF (could not be loaded during research)
• CISA: Product Security Bad Practices (v2.0, 17 Jan 2025)
• CISA: The Case for Memory Safe Roadmaps (6 Dec 2023)
• LWN: The (successful) end of the kernel Rust experiment (10 Dec 2025)
• DevClass: Rust boosted by permanent adoption for Linux kernel code (15 Dec 2025)
• Linux kernel documentation: Rust
• Linux kernel documentation: Rust architecture support
• Linux kernel documentation: Rust quick start
• Chromium: Memory safety
• TIOBE Index, October 2026
• Stack Overflow 2025 Developer Survey: Technology
• Stack Overflow: 2025 Developer Survey press release (29 Jul 2025)
• Rust Blog: 2024 State of Rust Survey results (13 Feb 2025)
• MITRE: 2025 CWE Top 25
• Safeguard: CISA memory safe languages roadmap
• Safeguard: Memory safety in the 2025 CWE Top 25
• Safeguard: How much vulnerability data is memory safety
• Safeguard: Rust memory safety CVE trend analysis
• Safeguard: Rust adoption in security critical software
• Safeguard: Memory safety roadmap checklist for product teams

Last reviewed: 23 October 2026. Figures change with each survey, index month and kernel release; check the linked sources for the latest values.