How Secure Are You?

“Uses CHERI” is not a complete security claim. A processor may implement CHERI instructions while an application still uses conventional pointers. A pure-capability application may have strong object bounds but run as one large component with access to every secret. A compartmentalised system may have narrow boundaries but still contain authentication or configuration flaws.

A useful security claim names what is being protected, the threats considered, and the supporting evidence. The following questions help turn a broad label into a testable description.

1. What are you protecting?

Start with assets and outcomes, not technology:

• customer or patient data
• cryptographic keys
• device control functions
• service availability
• safety-related state
• software update authority

Then identify which components hold or can reach each asset. A capability system can only enforce a useful policy if authority has been divided deliberately.

2. Which attackers and failures matter?

A threat model describes the conditions the design is expected to withstand. Consider whether an attacker can:

• send untrusted network data
• supply files or media for parsing
• install an untrusted extension
• compromise a third-party library
• gain local user access
• physically access the device
• observe timing or power use

Also consider accidental faults. CHERI can improve robustness even when no attacker is present by stopping invalid memory access closer to its source.

3. Which CHERI execution mode is used?

Ask what the relevant software actually does:

• Conventional binary on CHERI hardware: The hardware can run CHERI instructions, but this binary does not automatically gain fine-grained capability protection.
• Hybrid code: Selected pointers or interfaces use capabilities. The protection depends on where and how they are used.
• Pure-capability code: Pointers visible to the language use capabilities broadly, giving strong coverage for capability-enforced accesses.
• Compartmentalised code: Authority is divided between components. The outcome depends on the boundaries and the capabilities each component receives.

These modes describe related but distinct protections. A pure-capability application is not necessarily compartmentalised, and a hybrid application may protect only selected interfaces.

4. Which memory properties are enforced?

Check each relevant property separately:

• Spatial safety: Are accesses constrained to the intended object or allocation?
• Permissions: Are read, write, and execute rights reduced to what the code needs?
• Capability integrity: Can software forge or modify protected metadata?
• Temporal safety: What stops a stale capability being used after an object is freed and its memory reused?
• Control-flow protection: How are return addresses, function pointers, and protected entry points handled?

CHERI provides architectural building blocks, but some properties require compiler, allocator, operating-system, or runtime support. Temporal safety is an important example. Record the mechanism in use rather than assuming it from the processor alone.

5. How much authority does each component receive?

A component with a capability for all application memory can remain highly dangerous even if each access is technically within bounds. Review:

• capabilities available when the component starts
• capabilities accepted through interfaces
• services it can invoke
• capabilities it can retain or pass onwards
• whether shared memory is read-only or writable
• how the system revokes or replaces authority

Least privilege means giving each component only the authority required for its current task.

6. What evidence supports the claim?

Useful evidence may include:

• the architecture and implementation version
• compiler target and flags
• application binary interface (ABI) and operating-system mode
• software bill of materials
• porting diagnostics and resolved capability faults
• tests that deliberately exceed bounds or permissions
• compartment interface definitions
• threat modelling and security review
• independent assessment or scheme-specific certification
• performance and failure-recovery results for the real workload

A demonstration shows that one scenario worked. It is not automatically evidence for every build, platform, or attack path.

A more useful security statement

A broad statement might be:

The product is secure because it uses CHERI.

A more reviewable statement is:

The network parser runs as pure-capability code in a separate compartment. It receives a read-only capability bounded to one input buffer and a capability for one validated output queue. Tests confirm that out-of-bounds reads, writes, and unauthorised service calls fault without exposing application keys.

The second statement can be reviewed, tested, and improved. It also makes the remaining questions visible.

Key takeaways

• Treat CHERI as a set of enforceable mechanisms, not a single security level.
• Describe the protected asset, threat model, execution mode, and authority boundary.
• Distinguish spatial, temporal, and compartmentalisation claims.
• Tie every strong claim to evidence from the specific product and version.
• Continue to use secure design, testing, updates, and operational controls around CHERI.