Sandboxing & Policy Enforcement
Engineer/DeveloperSecurity SpecialistOperations & StrategyDevops
🔑 Key Takeaway
- Policy determines what is allowed; sandboxing limits damage when allowed actions go wrong.
- Enforce controls before execution, during runtime, and before promotion/deploy.
- Use both layers together to close gaps that either control leaves on its own.
Sandboxing and policy enforcement solve different problems and must be used together:
- Policy decides what should be allowed.
- Sandboxing limits damage when allowed actions fail, are abused, or are bypassed.
Using only one layer leaves material gaps.
Three policy checkpoints
| Checkpoint | Purpose | Typical examples |
|---|---|---|
| Pre-execution | block unsafe configuration before run starts | deny privileged runner flags, deny forbidden workflow triggers |
| Runtime | enforce constraints during execution | seccomp/AppArmor, pod security admission, network policy |
| Post-execution | verify integrity before promotion/deploy | signature verification, provenance checks, policy attestations |
CI/CD control stack
A practical stack for pipelines:
-
Workflow policy
- lint and validate pipeline definitions
- require least-privilege token settings
-
Runner/runtime policy
- enforce non-privileged execution
- require sandbox profile and resource limits
-
Artifact/release policy
- enforce signed artifacts and provenance before publish/deploy
-
Environment policy
- require approvals for production mutation paths
Threat-to-control mapping
| Threat | Policy control | Sandbox control |
|---|---|---|
| Secret exfiltration | deny secret injection into untrusted workflows | filesystem isolation + egress allowlist |
| Runner compromise | deny privileged execution configs | syscall filtering + ephemeral runner |
| Supply-chain tampering | require trusted source and attestation | isolated build runtime + immutable logs |
| Unauthorized deploy | branch/environment approvals | isolated deploy runner with scoped identity |
Maturity model
Level 1 (baseline)
- static policy checks for CI configuration
- isolated runners for untrusted PRs
- least-privilege CI tokens
Level 2 (intermediate)
- runtime admission/enforcement policies
- default-deny network egress
- short-lived credentials via federation
Level 3 (advanced)
- signed provenance verification on promotion
- policy decision logging with centralized audit
- periodic control validation exercises (breakout tests/tabletops)
Common anti-patterns
- Writing policy that is never enforced at runtime.
- Treating sandbox exceptions as permanent defaults.
- Failing open when policy engine is unavailable.
- Skipping auditability for policy decisions.
References
- NIST SP 800-53 Rev. 5 (policy, audit, and access controls): https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST SP 800-190, Application Container Security Guide: https://csrc.nist.gov/pubs/sp/800/190/final
- NIST SSDF (SP 800-218): https://csrc.nist.gov/pubs/sp/800/218/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
- Kubernetes, Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/
- Kubernetes, Admission Controllers: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
- SLSA specification: https://slsa.dev/spec/v1.0/overview