Lincoln Laboratory cybersecurity expert Hamed Okhravi calls for a unified approach to securing computer memory, as a matter of national security.
An illustration shows an iceberg with the earth balanced at the tip. To the left in a blue orb are digital systems, from fighter jets to smartwatches to cellphones. To the right is a red orb with an abstract eye emerging from a virus.
Memory-safety vulnerabilities are pervasive across computer systems. New technologies and unified efforts across government and industry can help change that. Illustration: Tammy Ko

Social security numbers stolen. Public transport halted. Hospital systems frozen until ransoms are paid. These are some of the damaging consequences of unsecure memory in computer systems.

Over the past decade, public awareness of such cyberattacks has intensified, as their impacts have harmed individuals, corporations, and governments. Today, this awareness is coinciding with technologies that are finally mature enough to eliminate vulnerabilities in memory safety.   

"We are at a tipping point — now is the right time to move to memory-safe systems," says Hamed Okhravi, a cybersecurity expert in MIT Lincoln Laboratory's Secure Resilient Systems and Technology Group.

In a January 2025 op-ed in Communications of the ACM, Okhravi joined 20 other luminaries in the field of computer security to lay out a plan for achieving universal memory safety. They argue for a standardized framework as an essential next step to adopting memory-safety technologies throughout all forms of computer systems, from fighter jets to cell phones.

Memory-safety vulnerabilities occur when a program performs unintended or erroneous operations in memory. Such operations are prevalent, accounting for an estimated 70% of software vulnerabilities. If attackers gain access to memory, they can potentially steal sensitive information, alter program execution, or even take control of the computer system. 

These vulnerabilities exist largely because common software programming languages, such as C or C++, are inherently memory insecure. A simple error by a software engineer, perhaps one line in a system’s multimillion lines of code, could be enough for an attacker to exploit. In recent years, new memory-safe languages, such as Rust, have been developed. But rewriting legacy systems in new, memory-safe languages can be costly and complicated.

Okhravi focuses on the national security implications of memory-safety vulnerabilities. For the U.S. Department of Defense (DoD), whose systems comprise billions of lines of legacy C or C++ code, memory safety has long been a known problem. The National Security Agency (NSA) and the federal government have recently urged technology developers to eliminate memory-safety vulnerabilities from their products. Security concerns extend beyond military systems to widespread consumer products. 

"Cell phones, for example, are not immediately important for defense or warfighting, but if we have 200 million vulnerable cell phones in the nation, that's a serious matter of national security," Okhravi says.

Memory-safe technology

In recent years, several technologies have emerged to help patch memory vulnerabilities in legacy systems. As the guest editor for a special issue of IEEE Security and Privacy, Okhravi solicited articles from top contributors in the field to highlight these technologies and the ways they can build on one another.   

Hamed Okhravi smiles for a photo, standing outside with the front entrance displaying "Lincoln Laboratory" in the background.
"We are at a tipping point — now is the right time to move to memory-safe systems," says Hamed Okhravi. Photo: Nicole Fandel

Some of these memory-safety technologies have been developed at Lincoln Laboratory, with sponsorship from DoD agencies. These technologies include TRACER and TASR, which are software products for Windows and Linux systems, respectively, that reshuffle the location of code in memory each time a program accesses it, making it very difficult for attackers to find exploits. These moving-target solutions have since been licensed by cybersecurity and cloud services companies.

"These technologies are quick wins, enabling us to make a lot of immediate impact without having to rebuild the whole system. But they are only a partial solution, a way of securing legacy systems while we are transitioning to safer languages," Okhravi says.

Innovative work is underway to make that transition easier. For example, the TRACTOR program at the Defense Advanced Research Projects Agency is developing artificial intelligence tools to automatically translate legacy C code to Rust. Lincoln Laboratory researchers will test and evaluate the translator for use in DoD systems. 

Okhravi and his coauthors acknowledge in their op-ed that the timeline for full adoption of memory-safe systems is long — likely decades. It will require the deployment of a combination of new hardware, software, and techniques, each with their own adoption paths, costs, and disruptions. Organizations should prioritize mission-critical systems first.

"For example, the most important components in a fighter jet, such as the flight-control algorithm or the munition-handling logic, would be made memory safe, say, within five years," Okhravi says. Subsystems less important to critical functions would have a longer timeframe.

Use of memory-safe programming languages at Lincoln Laboratory

As Lincoln Laboratory continues its leadership in advancing memory-safety technologies, the Secure Resilient Systems and Technology Group has prioritized adopting memory-safe programming languages. "We’ve been investing in the group-wide use of Rust for the past six years as part of our broader strategy to prototype cyber-hardened mission systems and high-assurance cryptographic implementations for the DoD and Intelligence Community," says Roger Khazan, who leads the group. "Memory safety is fundamental to trustworthiness in these systems."

Rust’s strong guarantees around memory safety, along with its speed and ability to catch bugs early during development, make it especially well suited for building secure and reliable systems. The Laboratory has been using Rust to prototype and transition secure components for embedded, distributed, and cryptographic systems where resilience, performance, and correctness are mission critical.

These efforts support both immediate U.S. government needs and a longer-term transformation of the national security software ecosystem. "They reflect Lincoln Laboratory’s broader mission of advancing technology in service to national security, grounded in technical excellence, innovation, and trust," Khazan adds.

A technology-agnostic framework

As new computer systems are designed, developers need a framework of memory-safety standards guiding them. Today, attempts to request memory safety in new systems are hampered by the lack of a clear set of definitions and practice.

Okhravi emphasizes that this standardized framework should be technology-agnostic and provide specific timelines with sets of requirements for different types of systems.

"In the acquisition process for the DoD and even the commercial sector, when we are mandating memory safety, it shouldn't be tied to a specific technology. It should be generic enough that different types of systems can apply different technologies to get there," he says.

Filling this gap not only requires building industrial consensus on technical approaches but also collaborating with government and academia to bring this effort to fruition.

The need for collaboration was an impetus for the op-ed, and Okhravi says that the consortium of experts will push for standardization from their positions across industry, government, and academia. Contributors to the paper represent a wide range of institutes, from the University of Cambridge and SRI International to Microsoft and Google. Together, they are building momentum to finally root out memory vulnerabilities and the costly damages associated with them.

"We are seeing this cost-risk tradeoff mindset shifting, partly because of the maturation of technology and partly because of such consequential incidents,” Okhravi says. “We hear all the time that such and such breach cost billions of dollars. Meanwhile, making the system secure might have cost 10 million dollars. Wouldn’t we have been better off making that effort?"

Media inquiries: contact Kylie Foy.