Rust, Go, Swift Become Non-Negotiable After NSA/CISA Guidance

What happened

On 16 Nov 2025 the National Security Agency (NSA) and Cybersecurity & Infrastructure Security Agency (CISA) issued a joint Cybersecurity Information Sheet urging wider adoption of memory‐safe programming languages (Rust, Go, Swift, Java, etc.) to reduce software vulnerabilities. That federal guidance, together with rising enterprise reporting and tooling momentum, is pushing memory safety from a best practice toward an expected baseline for new code.

Why this matters

Policy + market shift: stronger baseline for software security. The NSA/CISA guidance says memory-safety bugs remain the “most common” root cause of severe incidents, exposing systems to data breaches, crashes and operational disruption. The article cites Google/Android data showing a drop in memory‐vulnerability incidents for new code from roughly 76% (2019) to 24% (2024) after migrating new development toward Rust — evidence that adopting memory‐safe languages can materially cut risk without rewriting legacy C/C++ at once.

Organizations should expect:

• Engineering impact: prefer memory‐safe languages for new modules, use careful FFI and isolation for legacy C/C++.
• Operational & procurement impact: CTOs, security teams, insurers and regulators may increasingly require memory‐safety roadmaps for critical systems.
• Costs & trade-offs: rewrites are often infeasible; challenges include real‐time/performance constraints, immature niche tooling, and a skills gap (Rust learning curve).

Short term priorities are pragmatic: prioritize high‐risk components (networking, drivers, auth), invest in tooling (static analysis, fuzzing), and build training/hiring plans. The article estimates about 80% confidence that memory‐safe languages will become baseline expectation in critical domains within 1–2 years.

Sources

• NSA/CISA joint Cybersecurity Information Sheet (press release) — “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development” (16 Nov 2025): nsa.gov
• Coverage summarizing the guidance and adoption trends (CPO Magazine): cpomagazine.com

• Memory-related vulnerability share in Android new code — 24% (2024), down from ~76% in 2019, evidencing a major reduction enabled by shifting new development to memory-safe languages like Rust.

• Regulatory and procurement shift to a memory-safe baseline: NSA/CISA’s 2025-11-16 guidance and emerging requirements for national security systems and critical infrastructure move memory safety from “best practice” to an expected standard, raising compliance and contract-risk stakes for software suppliers and operators. Opportunity: Early adopters can win federal/regulated-sector bids and insurance advantages by demonstrating compliant roadmaps and measurable risk reduction.

• Legacy C/C++ exposure and migration constraints: Large, critical codebases cannot be fully rewritten, leaving persistent exposure to “severe risks” (data breaches, crashes, operational disruptions) unless organizations manage safe FFIs and prioritize new code in Rust/Go/Swift/Java; Android’s shift cut memory vulnerabilities in new code from ~76% (2019) to 24% (2024). Opportunity: Phased modernization—focusing memory-safe languages on new/high-risk components—can deliver rapid security gains and cost savings, benefiting platform owners and security-focused vendors.

• Known unknown: Toolchain/performance limits and mandate timelines—uncertainty remains around memory-safe language suitability for low-level/real-time domains, dependency ecosystem maturity, and when procurement requirements will extend beyond federal to sectors like banking/healthcare. Opportunity: Investing now in safer FFIs, static analysis/fuzzing for unsafe blocks, and migration tooling positions vendors and OSS maintainers to capture demand as adoption and compliance deadlines solidify.

Supporters call the new NSA/CISA guidance a turning point: memory safety moves from optional nicety to expected baseline, with enterprises, insurers, and customers tightening the screws. They point to Android’s measurable drop in memory vulnerabilities—from roughly 76% in new code to 24%—achieved not by rewriting the past but by mandating safe languages for the future. Skeptics counter that wholesale change is unrealistic: critical stacks in C/C++ won’t be swapped overnight, real-time niches still need low-level control, toolchains and ecosystems have gaps, and Rust’s learning curve is steep. Both sides concede the risk is real; NSA/CISA label memory issues the “most common” root cause of severe incidents. The hard question is pace and path. Declaring “use Rust” without resourcing training, FFI strategy, and tooling is theater. Yet clinging to legacy comfort also has a cost: shipping new network-facing code in C/C++ now reads less like craftsmanship and more like liability. Uncertainties linger—adoption metrics, time-bound commitments, and cross-language safety tools will test how far this can scale.

Here’s the twist the ARTICLE makes hard to ignore: the fastest route to safer software isn’t heroic rewrites—it’s ruthless discipline on new code. Purism takes a back seat to policy; define memory safety in your Definition of Done, migrate high-risk components first, fence legacy with safer interfaces, and watch the incident curve bend. If the federal guidance and Android’s results are prologue, procurement will start demanding safety by default, investors will prize it, and engineering leaders will track the share of unsafe code as closely as uptime. Watch adoption metrics from Android and major stacks, the emergence of safer FFI layers, and whether non-federal sectors import these requirements. With ~80% confidence that critical domains normalize memory-safe languages within 1–2 years, the next shift is cultural as much as technical. This is how “best practice” becomes baseline.