CISA and NSA releaseguidance for adopting memory-safe programming languages to nip decades-long system vulnerabilities in the bud.

For decades, memory-related vulnerabilities have been a persistent and costly challenge for cybersecurity professionals, frequently enabling devastating cyberattacks and compromising critical systems.

These vulnerabilities, which arise from programming errors in how software accesses or manages memory — such as buffer overflows; use-after-free; and dangling pointers — are especially common in languages such as C and C++, that lack built-in memory safety mechanisms. Industry studies consistently show that around 70% of severe security bugs are linked to memory safety issues, making them the most prevalent type of disclosed software vulnerability.

High-profile incidents such as Heartbleed and BadAlloc have illustrated the far-reaching consequences of these flaws, affecting everything from hospital records to industrial control systems. However, with last week’s announcement by the US Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) of a renewed push for systemic change, things are set to change for the better.

In a joint guidance document, the two agencies are urging software development teams and organizations to adopt memory-safe programming languages (called MSLs) such as Rust, Go, Java, Swift, Python, and C#, which incorporate automated memory management and compile-time checks to eliminate entire classes of vulnerabilities. The agencies stress that embedding memory safety at the programming language level shifts the responsibility from individual programmers to the tools themselves, offering a more robust and scalable defense against exploitation.

While acknowledging that transitioning legacy systems and large codebases to memory-safe languages presents challenges (including the need for developer training, tooling, and careful integration with existing software) the agencies emphasize that the long-term benefits for national security and software resilience are substantial. Their guidance provides practical strategies for adoption and highlights ways to harden existing non-memory-safe applications when a full transition is not feasible.

Nevertheless, recognizing that MSLs may not be the best option for every scenario, the US government’s message that efforts should take advantage of tools such as TRACTOR that can translate unsafe code through a Foreign Function Interface into MSL-compatible runtime code.