Using container as a throwaway sandbox for auditing untrusted dependencies

[sterngold]

We run a small security layer across a personal dev workspace, and one long-standing rule is: never run build/test/install for an untrusted or unclassified repo on the host. Until now that meant we just didn't run them, so a whole class of behavioural checks was off the table.

container changed that. The VM-per-container model is what made it click: each container is a full lightweight VM, so the host filesystem, SSH keys, and credentials simply don't exist inside it unless we mount them. A real isolation boundary, not namespace separation.

We wrote a small harness around it: mount the suspect repo read-only, install with lifecycle scripts disabled, run the test suite, all inside a disposable --rm VM. Validated end to end this week on Apple silicon (macOS 27): cloned a real third-party npm library, audited it, ran its 32 tests, and the host came back with no node_modules and nothing touched.

Two things we appreciated:

• --mount source=…,readonly plus the disposable VM made the "no writes reach the host" property trivial to prove.
• Sub-second warm starts make per-audit VMs genuinely practical.

One honest note for anyone using it this way: the VM walls off the host, and it does not by itself contain outbound network during a run that needs the registry (npm ci). We run static audits with no network attached for that reason. Not a complaint, just the boundary worth knowing.

Thanks for shipping this. It closed a real gap for us.

[jglogan]

@sterngold Thanks, and we're glad that container has been useful for you!