Sandbox or Adapter Wrapper¶
Containment wrapper — instantiates Substrate Lineage Risk Audit
Wraps an inherited substrate in an isolation-and-mediation boundary so its behavior and risk can only reach the rest of the system through a controlled channel.
A Sandbox or Adapter Wrapper is the containment response for the case the audit dreads and cannot fix: an inherited substrate you must keep using but cannot fully trust or remove. Rather than remove it, you interpose — a sandbox that confines what it can touch, an adapter that mediates and constrains the interface it speaks through, or both. Its defining move is to narrow the inheritance channel: the substrate keeps doing its job, but every path by which its behavior, its privileges, or a future compromise could reach the host is routed through a boundary you own and can reason about. It is accept-but-isolate — not removal, and not the decision about whether isolation is enough.
Example¶
A mobile app needs a third-party analytics SDK whose source the team cannot fully audit and whose upstream they do not control. Removing it isn't on the table this quarter, so they wrap it. First they model the inheritance channel: the SDK wants filesystem access, network egress, and a callback into app state — three routes by which its behavior enters the system. Then they interpose. The SDK runs with least privilege; its network calls go through an adapter that strips identifiers before anything leaves the device; its callbacks are validated at the boundary rather than trusted.[1]
Nothing about the SDK's own code changed. But if a future version is compromised upstream, the blast is confined to the sandbox — it cannot reach the filesystem it was never granted or exfiltrate the data the adapter never let past. The wrapper bought a bounded, reasoned-about relationship with a substrate the team could neither trust nor drop.
How it works¶
- Model the inheritance channel first. Enumerate exactly how the substrate touches the host — what data and control flow across the boundary, what privileges it holds, what it can invoke. You cannot narrow a channel you have not mapped.
- Interpose an isolation boundary. Place the substrate behind a confinement mechanism — a process sandbox, container, permission scope, or address-space boundary — sized to the channel model.
- Mediate the interface with an adapter. Where the substrate must still communicate, route it through an adapter that translates, validates, and constrains, rather than passing calls through raw.
- Grant least privilege across the boundary. Give the wrapped substrate only what its job strictly requires, so a compromise inherits only that.
Tuning parameters¶
- Isolation strength — from an in-process shim, to a separate process, to a container or full VM. Stronger isolation contains more but costs performance and integration effort.
- Channel width — how much the adapter lets through. A narrow channel contains tightly but may starve the substrate of what it legitimately needs; a wide one preserves function but leaks containment.
- Privilege scope — the exact capabilities granted across the boundary. Tighter scope shrinks the blast radius but risks breaking the substrate's real needs.
- Adapter fidelity — how faithfully the adapter mirrors the substrate's native interface. High fidelity eases integration but can mask breaking changes; a stricter adapter surfaces them but demands more maintenance.
- Containment vs. performance — how much overhead the isolation imposes. Heavier boundaries are safer and slower.
When it helps, and when it misleads¶
Its strength is that it lets you keep using a risky-but-necessary inherited substrate while capping how far it can hurt you — genuinely useful when removal is infeasible and buying time is the honest goal.
Its failure modes are subtle because the comfort is real. A wrapper is itself a new component that must be maintained, and a leaky sandbox or an over-wide adapter gives false confidence while quietly passing the risk through. An adapter that hides the substrate's breaking changes lets an incompatibility accumulate until it bites all at once. The classic misuse is "we sandboxed it" invoked as a reason to skip the rest of the audit — containment treated as absolution. The discipline is to treat wrapping as risk reduction, never risk removal: keep the isolated substrate on the remediation backlog, revisit the channel model when the substrate changes, and remember that a boundary you stopped scrutinizing is a boundary you no longer know the strength of.
How it implements the components¶
This tool fills the containment side of the archetype's machinery — the components that bound an inherited risk you have chosen to keep:
containment_or_isolation_boundary— the wrapper is the boundary; it confines the substrate's reach and blast radius to the sandbox rather than the whole host.inheritance_channel_model— placing the wrapper requires modeling exactly which channels carry the substrate's behavior into the host, then narrowing each; the model is what makes the containment principled rather than hopeful.
It does NOT decide whether isolation is sufficient to ship — that's Substrate Risk Release Gate — nor replace the substrate outright — that's Clean-Room Rebuild or Replatforming Pilot. The wrapper contains; its siblings adjudicate and remediate.
Related¶
- Instantiates: Substrate Lineage Risk Audit — it is the containment option for inherited risk the audit cannot remove.
- Consumes: the findings from Transitive Vulnerability Scan and the Substrate Risk Release Gate's decision determine what needs wrapping and how tightly.
- Sibling mechanisms: Substrate Risk Release Gate · Clean-Room Rebuild or Replatforming Pilot · Inherited Permission Review · Legacy Substrate Architecture Review · Transitive Vulnerability Scan
Notes¶
Containment is a holding action, not a fix. The wrapped substrate is still risky; you have only limited how far the risk can travel — and you have added a boundary that now needs its own upkeep. The moment the wrapper is treated as a permanent solution, the underlying inherited risk quietly falls off everyone's list, which is exactly when it matures. Pair it with a live entry on the remediation backlog.
References¶
[1] The principle of least privilege — that a component should hold only the access its task strictly requires — was articulated by Saltzer and Schroeder in their 1975 survey of protection in computer systems. It is the real principle a sandbox operationalizes: minimizing granted capability minimizes what a compromise of the wrapped substrate can inherit. ↩