Why CHERI
How secure are you?
Security is not a single score; this practical self-check helps teams identify native-code exposure, trust boundaries, long lifetimes and containment needs.
Why it matters
These questions help prioritise architecture work; they do not replace a threat model, code review or security assessment.
In brief
Security is not a single score. A useful CHERI readiness discussion asks where memory-unsafe code handles untrusted data, which components hold broad authority, how long the product must be supported and what happens when a component fails.
Text-only self-check
Use these questions to structure a conversation. This is educational decision support, not a security audit.
- Does the product include C or C++ code?
- Does it accept data from a network or another untrusted source?
- Must it remain supported for more than five years?
- Does it combine firmware, an operating system and third-party components?
- Could one compromised component affect a critical function?
More “yes” answers do not create a security score. They indicate where it may be useful to map trust boundaries, long-lived components and containment options.
Key considerations
1. Exposure
Identify C/C++, unsafe code, network or file parsers, third-party components and remotely reachable interfaces.
2. Consequence
Map the data, functions and services each component can reach if compromised.
3. Lifecycle
Review update capability, field access, supplier support, certification and years of expected deployment.
Evidence and caveats
A high number of risk indicators does not prove vulnerability, and a low number does not prove safety. Use evidence and qualified review.
Use evidence from a named system or source and keep claims proportionate. CHERI is one layer in a broader secure-design strategy.