Business & Policy
Rewrite costs and risks
Replacing memory-unsafe code with a memory-safe language can prevent broad classes of defects, but a full rewrite carries delivery, compatibility and regression risk.
Why it matters
The right strategy is usually a portfolio of controls chosen by component, not an argument for one universal migration method.
In brief
Replacing memory-unsafe code with a memory-safe language can prevent broad classes of defects, but a full rewrite carries delivery, compatibility and regression risk. CHERI offers another route: adapt and recompile existing C and C++ while adding hardware-enforced pointer protection, then combine this with selective rewrites where they add most value.
Key considerations
1. Rewrite selectively
Prioritise new components and high-risk modules where ownership and interface redesign are feasible.
2. Protect existing code
Evaluate CHERI for mature native code, mixed-language systems and dependencies that cannot be replaced quickly.
3. Strengthen boundaries
Use compartmentalisation between components so one remaining flaw has less authority over the system.
Evidence and caveats
Neither recompilation nor a language rewrite is automatic. Both require dependency work, testing, skilled engineers and a maintained target platform.
Show assumptions, ranges, dates and owners for economic or policy claims. Recheck legislation, guidance, product status and prices at the decision date.