Cost of Memory Unsafety
Memory-safety failures create costs across incident response, engineering, support, assurance, and lost opportunity, not just the cost of fixing a defect.
Memory errors can turn a small coding mistake into data exposure, code execution, a crashed service, or a route from one component into another. The visible patch is often the least expensive part of the event.
Count the whole cost
An organisation’s baseline should include costs before, during, and after a vulnerability is found.
- Before discovery, costs may include reviews, fuzzing, static analysis, hardening, specialist training, and overlapping controls.
- During discovery, teams spend time on triage, reproducing the defect, assessing whether it can be exploited, coordinated disclosure, and bug bounties.
- During response, costs can include incident handling, emergency releases, customer communication, and fleet updates.
- After an incident, an organisation may face downtime, lost data, contractual penalties, legal work, and harm to users.
- Across the remaining product life, backports, extended support, certification updates, insurance, and delayed product work can continue to add cost.
Memory unsafety also creates uncertainty. A defect discovered in a shared library may affect many products, versions, and customers. Teams must establish which builds contain the code, whether the defect is reachable, and whether existing mitigations stop a practical attack.
Establish a useful baseline
Start with evidence your organisation already holds:
- Count memory-safety defects and incidents over a representative period.
- Record engineering hours from report to supported fix, including backports.
- Identify products that share vulnerable native code.
- Measure service disruption, release delay, and assurance rework.
- Separate confirmed costs from estimated exposure.
Do not assume every crash would become an exploit. Conversely, do not count only exploited vulnerabilities. Near misses, emergency investigations, and deferred features consume real resources.
Why architecture matters
Conventional mitigations can make exploitation harder, but they often do not stop the invalid access itself. CHERI-capable processors attach bounds, permissions, and validity to references used by software. The processor can reject an access that exceeds the authorised object or attempts a disallowed operation. Compartments can also restrict what a compromised component is able to reach.
That changes the risk model in two ways: some defects can be stopped at the point of access, and the consequences of a successful compromise can be reduced. It does not remove the need for secure design, testing, updates, or memory-safe languages.
Use ranges, not a headline number
Model low, expected, and high cases. State assumptions such as product lifetime, defect rate, affected fleet, adoption scope, and residual risk. The result is a decision aid, not a promise that a particular percentage of security cost will disappear.
For industry context, see CISA’s case for memory-safe roadmaps and the Google Security Blog’s account of memory-safety work. Use your own evidence for an investment decision.