Sandboxing & Policy Enforcement

Engineer/DeveloperSecurity SpecialistOperations & StrategyDevops

Authored by:

munamwasi

jubos

masterfung

Reviewed by:

matta

The Red Guild | SEAL

🔑 Key Takeaway: Policy decides what may run and sandboxing limits damage if it fails, so both must be enforced before, during, and after execution to close control gaps.

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
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/