Cost of Memory Unsafety
Memory-safety failures can create costs across a product's life, from urgent engineering work to service disruption, lost trust, and delayed development.
A memory error may begin as one incorrect read, write, or use of an object after its lifetime has ended. In software that handles messages, payments, personal data, industrial controls, or network traffic, that error can become a crash, data exposure, unauthorised code execution, or a route into another component.
The cost is rarely limited to correcting one line of code. It can spread across engineering, operations, customer support, product assurance, and future development.
Why the costs spread
Memory-unsafe languages such as C and C++ remain important in operating systems, devices, vehicles, cloud infrastructure, and other performance-sensitive software. The same library may appear in many products and versions. When a vulnerability is found, its true reach may be unclear for days or weeks.
The resulting work can include:
- reproducing the fault and establishing whether it is exploitable;
- finding every affected product, version, dependency, and customer;
- preparing, testing, and distributing urgent fixes and backports;
- responding to incidents, service interruptions, and support requests;
- repeating assurance or certification activity after a change;
- delaying planned features while specialist teams handle the issue.
Some costs appear even when no attack takes place. Investigations, emergency release processes, defensive controls, and uncertainty about older products all consume time and money.
What CHERI changes
CHERI gives the processor more information about every protected memory reference. A capability records where software may access memory, the permitted range, and operations such as reading, writing, or executing. The processor can reject an access that falls outside that authority.
This changes the role of protection. Conventional mitigations often make a memory bug harder to exploit; CHERI can stop many invalid accesses at the point where they occur. CHERI compartments can also restrict a component to a defined set of memory and services, reducing what an attacker can reach if that component is compromised.
Not every software fault disappears, and temporal memory safety requires suitable allocation and revocation mechanisms as well as the base capability architecture. Secure design, testing, updates, and other controls remain part of the system.
Where CHERI may be a strong fit
The economic case is often clearest where several conditions overlap:
- established C or C++ code cannot be replaced quickly;
- software processes untrusted or complex input;
- a vulnerable component has access to valuable data, devices, or services;
- the same code is reused across a large product family or fleet;
- products remain supported for many years;
- process-level isolation is unavailable or too coarse for the required boundary.
In these settings, CHERI can reduce exposure while preserving much of the existing software investment. Memory-safe languages may remain the better fit for new components, and the two approaches can be used together.
The wider business effect
The value of CHERI is not confined to an avoided breach. Earlier fault detection can shorten diagnosis. Smaller compartments can reduce the number of systems affected by one defect. More explicit authority can make security claims easier to explain and test. Together, these effects can reduce uncertainty across development, operation, and long-term support.
CISA’s case for memory-safe roadmaps describes memory safety as a strategic product issue. CHERI adds a hardware-supported route for the large body of low-level and existing software that remains difficult to replace.