The Memory Safety Reckoning: Part 1 of 4
This article is the first installment in The Memory Safety Reckoning, a four-part series examining the business, security, and operational challenges posed by memory-unsafe software and the path toward more resilient systems.
Why Memory Safety Became a National Security Priority
Modern society runs on software, and the consequences of software failure have never been higher. One class of vulnerability, rooted in how software manages memory, has proven more persistent, more exploitable, and more damaging than almost any other.
Memory safety became a national priority because the conditions that once made it a secondary concern no longer exist. For much of computing history, developers focused primarily on functionality, performance, and compatibility, and many systems were isolated enough that security could be treated as an afterthought. As software became deeply networked and embedded in critical infrastructure, memory corruption emerged as one of the most persistent and exploitable classes of vulnerability in existence.
For decades, the industry responded not by moving away from the languages most prone to these issues, but by layering on mitigations — protections built into compilers, operating systems, and processor architectures designed to make exploitation harder. These measures raised the bar for attackers, but they did not eliminate the underlying problem. The result has been a long cycle of new defenses met by new exploitation techniques, with memory corruption remaining responsible for a disproportionate share of serious vulnerabilities year after year.
Microsoft’s Security Response Center reported that approximately 70% of the vulnerabilities assigned CVEs by Microsoft over a 12-year period were memory safety vulnerabilities. Similar findings have been cited by CISA, the NSA, and the White House Office of the National Cyber Director (ONCD), all of which have identified memory-related flaws as one of the most significant sources of exploitable software risk.
That persistence is what elevated the lack of memory safety from an engineering concern to a national security one. When the same class of vulnerability continues to fuel breaches in critical infrastructure, defense systems, and government networks despite decades of effort, policymakers can no longer treat it as a problem for developers alone to solve.
Understanding the Memory Safety Problem
Memory safety vulnerabilities occur when software accesses memory in unintended ways. Common examples include:
- Buffer overflows
- Use-after-free vulnerabilities
- Out-of-bounds reads and writes
- Double-free errors
- Access to uninitialized memory
These vulnerabilities arise when a program loses track of what memory it owns, when that memory is valid, or how much data it can safely hold.
Not all software vulnerabilities share the same root cause. Some arise from logical errors in program design; others reflect unsafe architectural decisions. Memory safety vulnerabilities, however, stand apart — they appear consistently across virtually every software domain, and when it comes to serious, high-impact exploits, they dominate all other categories by a significant margin. Many of the most consequential software attacks over the last three decades have ultimately traced back to memory safety failures.
From a security perspective, this matters because memory corruption vulnerabilities are uniquely dangerous: they often allow attackers to execute arbitrary code, escalate privileges, bypass security controls, or access sensitive data. Unlike many other vulnerability classes, they are not edge cases or implementation accidents — they are a predictable consequence of using languages that place the burden of memory management entirely on the developer.
Why Governments Are Prioritizing Memory-Safe Languages
Historically, cybersecurity efforts focused on identifying and mitigating vulnerabilities after software had already been deployed. Organizations invested heavily in vulnerability scanning, endpoint protection, intrusion detection, and patch management. While these approaches remain necessary, they largely place the burden of managing security risk on the organizations that deploy and operate software rather than on those who produce it.
In recent years, government agencies have begun advocating for approaches that reduce vulnerability classes at their source. This reflects a broader shift in thinking: rather than relying primarily on downstream defenses to compensate for insecure software, policymakers increasingly encourage software producers to adopt practices and technologies that prevent common vulnerabilities from being introduced in the first place. In many ways, this mirrors building codes and safety regulations in other industries, where responsibility for safety is embedded into the design and construction process rather than left entirely to the occupants.
This philosophy is reflected in concrete policy actions. The White House’s Secure by Design Initiative and the ONCD’s report, Back to the Building Blocks: A Path Toward Secure and Measurable Software, both identify memory safety as a foundational software security challenge — and both specifically encouraged the adoption of memory-safe programming languages such as Rust, Go, Java, C#, and Swift as a practical path forward. Similar recommendations have also been made jointly by CISA and the NSA.”
The reasoning is straightforward: while memory-safe languages don’t eliminate logic errors, design flaws, or other software defects, they do make broad classes of memory corruption vulnerabilities impossible by construction. From a risk-reduction standpoint, that matters: preventing an entire category of vulnerabilities is fundamentally more effective than continuously detecting and patching individual instances of the same underlying problem.
Why C and C++ Continue to Dominate Critical Systems
If memory safety is such a well-understood issue, a natural question follows: why are memory-unsafe languages still so prevalent?
The answer lies in decades of technological investment.
C and C++ remain foundational to modern computing. They power operating systems, embedded devices, industrial control systems, networking equipment, aerospace platforms, telecommunications infrastructure, and countless commercial software products.
Organizations continue to rely on these languages because they provide:
- Direct hardware access
- Fine-grained memory control
- High performance
- Mature development ecosystems
- Large pools of experienced developers
- Decades of existing production code
For many organizations, migrating millions of lines of existing code into a memory-safe language is neither technically feasible nor economically practical.
This creates a reality in which memory-safe and memory-unsafe software coexist throughout the enterprise. Most organizations are not deciding whetehr to eliminate the use of C and C++ entirely; they are deciding where modernization efforts will have the greatest impact and how to manage the risks associated with existing codebases.
Why Visibility Is the Missing Piece
The conversation around memory safety often focuses on programming languages and modernization efforts, but organizations frequently face a more immediate challenge: they do not know where their memory-unsafe code exists.
Most enterprises operate a combination of internally developed software, legacy applications, commercial products, and open-source dependencies. Some of these systems may contain significant amounts of C or C++ code, while others may depend on third-party components that introduce memory-related risk. Even languages designed with memory safety in mind often include “escape hatches” — mechanisms that allow developers to step outside those protections when needed. Rust, for example, has unsafe blocks, and Java exposes native code through its JNI interface. In both cases, these features can quietly reintroduce the very risks the language was designed to eliminate.
Before organizations can make informed decisions about migration, remediation, or modernization, they need visibility into their software environment. Understanding where memory-unsafe code exists, and which systems are most critical to business operations, provides the foundation for a practical memory safety strategy.
Without that visibility, organizations risk prioritizing the wrong systems or overlooking critical sources of exposure.
The Strategic Shift Toward Secure by Design
The growing emphasis on memory safety reflects a broader transformation in cybersecurity strategy.
Traditional security models assume vulnerabilities will exist and focus on detecting them quickly. Secure-by-Design approaches seek to reduce the number of vulnerabilities that can exist in the first place.
Memory safety is often cited as a textbook example of this philosophy. Instead of finding and patching thousands of individual buffer overflows, organizations can adopt technologies and development practices that make such vulnerabilities substantially less likely to occur.
This shift is increasingly reflected in public policy. The National Cybersecurity Strategy argues that software manufacturers should bear greater responsibility for reducing systemic risk through secure development practices rather than relying solely on downstream users to manage security problems after deployment.
Viewed through this lens, memory safety is not simply a programming language discussion. It is a strategy for reducing an organization’s long-term exposure to one of the most persistent sources of software vulnerabilities.
What Organizations Should Do Next
Most organizations have limited visibility into how much memory-unsafe code exists within their environment. Legacy applications, internally developed software, open-source dependencies, and commercial products may all contribute to overall exposure.
As regulators, government agencies, and technology providers continue to prioritize memory safety, organizations will increasingly need to understand where memory-related risks exist and how those risks align with critical business functions.
The objective is not necessarily to replace every legacy system. Instead, organizations should focus on identifying high-risk software assets, understanding their exposure to memory corruption vulnerabilities, and developing a realistic roadmap for risk reduction.
Assess your organization’s exposure to memory-unsafe code. Understanding where memory-related risk exists is the first step toward building an effective memory safety strategy.
Want to understand the broader business impact of legacy software? Check out the next post in this series, “The Hidden Cost of Legacy C++,” that will be coming out later this month.