Government Guidance
Public guidance increasingly treats memory safety as a strategic product issue, creating a clear role for CHERI alongside memory-safe languages and established controls.
Governments and national cybersecurity authorities increasingly describe memory safety as a product-security and resilience issue, not only a programming concern. Their interest reflects the repeated role of memory vulnerabilities in widely used software and the difficulty of replacing every established C and C++ component.
This policy direction creates a clear place for CHERI. Memory-safe languages can prevent broad classes of errors in new code. CHERI can bring processor-enforced memory protection to low-level and existing software while also limiting the authority of individual components.
The direction of public guidance
CISA’s Case for Memory Safe Roadmaps presents memory safety as a strategic responsibility for software manufacturers. It focuses on measurable plans for reducing reliance on memory-unsafe languages and making progress visible to customers.
CISA’s work on critical open-source projects also recognises that widely used dependencies form part of the exposure. This is important because a product may contain native code that its own development team did not write.
The UK National Cyber Security Centre describes memory-safe languages and hardware approaches as parts of a wider secure-by-design landscape. Its discussion of raising software resilience at scale identifies CHERI as one of the technology approaches that can contribute to a more resilient ecosystem.
The UK’s Digital Security by Design programme provided a major public investment in CHERI research, the Morello platform, software, and industrial evaluation.
Where CHERI adds to the policy picture
Language change is a strong route for new software, while public policy also covers operating systems, device firmware, infrastructure, and other native code that will remain in use for years. CHERI is relevant to that part of the problem.
Its contribution has two dimensions:
- memory protection: many invalid accesses can be rejected by the processor;
- compartmentalisation: a component can be restricted to specific memory and services, limiting the effect of compromise.
These properties support policy goals around secure-by-design products, vulnerability reduction, resilience, and the protection of legacy investment. They also make CHERI complementary to language migration rather than a competing universal answer.
Why a portfolio can include CHERI
Different software presents different constraints. A new internet service may be well suited to Rust. An established C library may be too costly to replace but suitable for pure-capability compilation. A third-party parser may benefit from both capability-aware code and a restricted compartment.
CHERI’s policy relevance lies in widening the available routes to memory safety. It offers a way to cover software that might otherwise remain dependent on exploit mitigations alone, and it adds containment when preventing every defect is unrealistic.
Guidance, standards, and law
Public guidance explains direction and expected outcomes; it does not itself certify a product or establish legal compliance. CHERI also does not supply secure updates, vulnerability disclosure, incident response, or complete lifecycle governance.
Its potential fit is architectural: stronger memory boundaries can support the secure and resilient products that guidance increasingly calls for, while the wider product and organisation provide the remaining controls.