Sandboxing & Isolation

Engineer/DeveloperSecurity SpecialistOperations & StrategyDevops

Authored by:

matta

The Red Guild | SEAL

🔑 Key Takeaway

Assume untrusted execution can fail or be compromised, then design containment by default.

Apply layered controls across identity, runtime, filesystem, network, and resources.

Increase isolation depth as risk increases (container hardening → sandboxed containers → microVM/VM).

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 (read by 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
CISA, Defending Continuous Integration/Continuous Delivery (CI/CD) Environments: https://www.cisa.gov/resources-tools/resources/defending-continuous-integrationcontinuous-delivery-cicd-environments
CISA, Defense in Depth: https://www.cisa.gov/resources-tools/resources/defense-depth
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/overview