Sandboxing & Isolation
🔑 Key Takeaway: Assume execution can be untrusted and apply layered containment across identity, runtime, filesystem, network, and resources, increasing isolation strength with workload risk.
This section is the DevSecOps guide for running untrusted or semi-trusted execution safely: CI jobs, pull request validation, build scripts, plugins, package hooks, internal automation, and AI agents (as one automation category among many).
The core objective is simple: assume compromise can happen, then contain blast radius by design.
What to protect (threat model quickstart)
Treat sandboxing decisions as a threat-modeling exercise across four dimensions:
| Dimension | Questions to answer |
|---|---|
| Assets | What can be stolen or modified? (source code, signing keys, CI secrets, deployment credentials, artifacts, production APIs) |
| Entry points | What can trigger execution? (fork PRs, dependencies, build scripts, test fixtures, webhooks, external APIs) |
| Privileges | What authority does runtime hold? (filesystem write, network egress, cloud IAM, package publish, deployment rights) |
| Impact | What is worst-case outcome? (secret exfiltration, artifact tampering, lateral movement, production change, financial loss) |
Default assumption: code from external contributors, third-party actions, and newly introduced dependencies are untrusted until verified.
Decision tree: choose isolation depth
Use this practical decision flow before assigning a runtime:
-
Does the workload process untrusted input or untrusted code?
- If yes, run in an ephemeral sandbox (container with hardened profile at minimum; microVM/VM for higher assurance).
-
Can the workload access secrets, signing keys, cloud credentials, or production systems?
- If yes, enforce stronger isolation boundary, short-lived credentials, and explicit approval gates.
-
Is outbound network required?
- If no, deny all egress.
- If yes, allowlist destinations and force traffic through inspection/proxy controls.
-
Can it modify persistent state (artifact repo, registry, infra, chain, database)?
- If yes, require policy checks + attestation + auditable identity before execution.
-
Is this multi-tenant shared runner infrastructure?
- If yes, isolate per job with ephemeral workers and avoid secret reuse across jobs.
If you answer “yes” to multiple high-risk questions, prefer microVM/VM isolation plus strict policy enforcement.
Layered control map (defense in depth)
No single mechanism is sufficient. Apply multiple layers together:
| Layer | Control objective | Typical controls |
|---|---|---|
| Identity | Bind execution to least privilege identity | OIDC federation, short-lived tokens, scoped IAM roles |
| Execution boundary | Prevent host escape / cross-tenant impact | seccomp, AppArmor/SELinux, rootless containers, gVisor/Kata/Firecracker |
| Filesystem & secrets | Prevent sensitive data exposure | read-only rootfs, isolated workdir, mounted secret scopes, no long-lived credentials |
| Network | Prevent exfiltration and lateral movement | default-deny egress, DNS restrictions, NetworkPolicy, egress proxy |
| Resource governance | Prevent abuse and runaway cost | CPU/memory/pids/time limits, quotas, job timeout, concurrency caps |
| Integrity & provenance | Detect tampering and unauthorized changes | signed artifacts, provenance attestations, immutable logs, SLSA controls |
| Policy & response | Enforce and verify continuously | policy-as-code gates, runtime audit logs, alerting, incident playbooks |
Baseline controls for CI/CD and runners
At minimum, enforce the following:
- Separate untrusted PR runners from trusted build/deploy runners.
- Use ephemeral runners (fresh environment per job, no state reuse).
- Disable or heavily constrain secrets for forked PR jobs.
- Restrict CI token scopes to least privilege (
readby default). - Deny outbound network by default; allow only required hosts.
- Run with syscall and privilege restrictions (
seccomp, no privileged mode, no host mounts unless strictly required). - Sign and attest release artifacts before publish/deploy.
Start here (section map)
- Execution Sandboxing — principles and runtime design choices.
- Execution Sandboxing: A Practical Guide — implementation blueprint for teams and platforms.
- Network & Resource Isolation — egress controls, quotas, and anti-exfiltration patterns.
- Sandboxing for Tool Execution — controlling high-risk tool calls and side effects.
- Capability-Based Isolation — breaking broad permissions into constrained capabilities.
- Sandboxing & Policy Enforcement — integrating policy-as-code with runtime isolation.
References
- NIST SP 800-190, Application Container Security Guide: https://csrc.nist.gov/pubs/sp/800/190/final
- NIST SP 800-53 Rev. 5, Security and Privacy Controls: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- Linux kernel documentation, Seccomp BPF: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html
- Docker, Docker Engine Security: https://docs.docker.com/engine/security/
- Kubernetes, Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/
- SLSA specification: https://slsa.dev/spec/v1.0/