Compartmentalisation

Why it matters

This shifts the question from whether every component is perfect to what damage a compromised component can cause.

In brief

How can one compromised component be stopped from taking over the whole system?

Compartmentalisation divides software into components that hold only the capabilities needed for their job. A vulnerability inside one component then has less authority to read, modify or control the rest of the system.

Key considerations

1. Boundary

Choose components and entry points based on trust, data sensitivity and recovery needs.

2. Authority

Delegate narrow capabilities and services; minimise shared writable state and ambient access.

3. Operation

Define call, fault, restart, logging and update behaviour so containment remains usable.

Evidence and caveats

A compartment with broad delegated capabilities or unsafe shared interfaces provides weak containment. Design and test the boundary as part of the security model.

Use the exact architecture and software specification implemented by the target. Separate architectural guarantees from system-level outcomes.

Primary routes

• University of Cambridge CHERI