Establishing Container Security Policies for Your Organization

Container Security Policy Framework

Document Version: 1.0 Last Updated: 2026-03-22 Classification: Internal - CISO/GRC Use Approval: CISO, VP Engineering, Compliance Officer Review Cadence: Annual or upon material security change

1. Purpose and Scope

This policy establishes minimum security requirements for container images, deployments, and runtime behavior across all CleanStart-managed infrastructure. It applies to:

All container images pulled from or deployed via CleanStart infrastructure. All Kubernetes clusters using CleanStart container orchestration. All CI/CD pipelines building or deploying containers. All development, staging, and production environments. All third-party container images running in CleanStart-governed clusters.

Non-Scope: This policy does not cover virtual machines, serverless functions, or non-containerized workloads, which are governed by separate policies.

2. Policy Statement

CleanStart enforces a zero-trust container security model based on:

1. Image Integrity: All container images must be cryptographically signed and verifiable
2. Supply Chain Transparency: All dependencies must be enumerated in machine-readable SBOMs
3. Vulnerability Remediation: All known vulnerabilities must be remediated within defined SLAs
4. Runtime Hardening: All containers must run with minimal privileges and restricted system access
5. Admission Control: All workloads must pass policy validation before deployment
6. Continuous Monitoring: All runtime behavior must be monitored for anomalies and threats
7. Audit and Accountability: All policy decisions and exceptions must be logged and auditable

3. RACI Matrix

3.1 Image Selection and Approval

R = Responsible | A = Accountable | C = Consulted | I = Informed

3.2 Image Building and Signing

3.3 Vulnerability Scanning and Remediation

3.4 Deployment and Admission Control

3.5 Runtime Monitoring and Incident Response

3.6 Compliance and Audit

3.7 Secret Management

3.8 Network Security

4. Specific Policy Requirements

4.1 Image Source and Registry

Requirement: All container images MUST originate from an approved registry.

Approved registries: registry.cleanstart.com (CleanStart-built images) Explicitly approved public registries (Docker Hub organization, Quay.io organization) — requires CISO sign-off. Prohibited: Images from personal Docker Hub accounts Images from unvetted public registries Images built outside the CleanStart build pipeline Images without verifiable provenance. Enforcement: Kyverno and OPA/Gatekeeper rules enforce allowlisting by registry. Exception Process: Engineering may request addition of a registry via exception form (Section 5).

4.2 Image Signature Verification

Requirement: All images MUST be signed with Cosign and signatures MUST be verified before deployment.

Signing standard: Cosign with keyless (Sigstore) or key-based signing. Verification timing: CI/CD pipeline (mandatory) and admission control (redundant). Key rotation: Cosign signing keys MUST be rotated annually and upon suspected compromise. Verification failure: Any unsigned or invalid signature is a deployment blocker. Enforcement: CI/CD job: cosign verify --certificate-identity-regexp=... <image> Admission control: Kyverno policy blocks unsigned images Registry webhook: Optional — re-verify on pull. Non-Compliance Impact: Image cannot be deployed; manual CISO approval required (rare exception).

4.3 Software Bill of Materials (SBOM)

Requirement: All images MUST include an SBOM in SPDX and CycloneDX format.

SBOM Content: All base OS packages (dpkg, rpm, apk, etc.) All application dependencies (npm, pip, Go modules, Maven, Cargo, etc.) All indirect/transitive dependencies License metadata for each component Component versions and hashes. Generation: CleanStart build pipeline auto-generates SBOMs; no manual creation needed. Storage: SBOM stored as image attestation (OCI artifact) and accessible via cosign sbom download <image>. Verification: CI: cosign sbom download <image> must succeed Admission: SBOM presence checked for PCI/audit compliance Updates: SBOM diffed between image versions for dependency changes. Retention: SBOMs retained for minimum 7 years for compliance audits.

4.4 Non-Root User Requirement

Requirement: All containers MUST run as a non-root user.

Standard UID: 65532 (unprivileged user, widely recognized). Dockerfile enforcement: USER 65532 in final image layer. Validation: Admission control verifies runAsNonRoot=true in deployment spec. Exception process: Requires CISO approval + risk assessment (rare). Purpose: Limits blast radius if container is compromised; attackers cannot modify system files or escalate privileges. Enforcement: Dockerfile linting: Build fails if USER directive missing Admission control: Kyverno rule blocks securityContext.runAsUser=0 Runtime monitoring: Falco alerts on unexpected privilege escalation attempts.

4.5 Read-Only Root Filesystem

Requirement: All containers MUST run with a read-only root filesystem.

Configuration: securityContext.readOnlyRootFilesystem: true in Kubernetes spec. Writable paths: Only /tmp and application-specific directories (e.g., /var/cache/app) may be writable. Mount volumes: Use emptyDir or persistent volumes for state. Purpose: Prevents attackers from planting backdoors, modifying application code, or tampering with system binaries. Enforcement: Admission control: Kyverno rule enforces read-only root filesystem Testing: Build verification confirms application works in read-only mode Runtime monitoring: Falco alerts on attempt to write to root filesystem. Exception: Requires security architecture review and CISO approval.

4.6 Capability Dropping

Requirement: All containers MUST drop all Linux capabilities unless explicitly approved.

Default policy: securityContext.capabilities.drop: ["ALL"]. Approved capabilities (whitelist-only): NET_BIND_SERVICE (only for services binding to ports <1024; generally unnecessary with UID 65532) Others: Requires CISO and security architect review. Purpose: Limits kernel-level attacks; containers should not need raw socket access, process tracing, or system administration capabilities. Enforcement: Admission control: Kyverno rule blocks any capability not in whitelist Violation escalates to CISO for review.

4.7 Admission Control Policies

Requirement: All deployments MUST pass both Kyverno and OPA/Gatekeeper policy validation.

Kyverno policies: Image from approved registry Image signed (Cosign valid) Non-root user (UID 65532) Read-only root filesystem All capabilities dropped Resource limits defined (CPU, memory) No privileged containers No host networking. OPA/Gatekeeper policies (additional governance): No images with Critical/High vulnerabilities in current SLA violation window Required labels (team, env, compliance, cost-center) Network policies attached to all pods Pod Disruption Budgets defined for prod workloads. Failure modes: Kyverno violation: Deployment rejected; engineering must remediate Gatekeeper violation: Deployment blocked; exception requires CISO approval Manual override: Requires incident ticket, CISO sign-off, and 24-hour review window.

4.8 Vulnerability Scanning and Remediation SLAs

Requirement: All newly discovered vulnerabilities in deployed images MUST be remediated within defined SLAs.

4.8.1 SLA Table

4.8.2 Tracking and Verification

Tracking system: CVEs tracked in issue tracking system (Jira/GitHub Issues) with SLA deadline, severity, affected images, remediation status. Verification: Re-scan patched image to confirm vulnerability no longer present Compare SBOM before/after to verify dependency update Attestation: Engineer signs off on remediation completion. Non-compliance: Breach of Critical/High SLA escalates to VP Engineering and CISO. Variance reporting: Monthly SLA compliance dashboard to GRC team.

4.8.3 Exception Process for SLA Variance

If a vulnerability cannot be remediated within SLA (e.g., upstream delay, architectural constraint):

1. Document: Root cause, estimated remediation date, compensating controls
2. Risk assessment: Security architect evaluates residual risk
3. Compensating controls: Implement if possible (network isolation, WAF rules, etc.)
4. Approval: CISO and VP Engineering joint approval
5. Escalation: Executive sponsor tracks; monthly review until remediated
6. Audit trail: Stored for compliance verification

4.9 Image Updates and Patching

Requirement: The upgrade model MUST be image-based; in-place patching is prohibited.

Patch deployment: Pull new image version from registry.cleanstart.com. Process.

1. Scan new image for vulnerabilities
2. Review SBOM for dependency changes
3. Deploy to staging environment
4. Run integration and performance tests
5. Canary deploy to production (10% → 50% → 100%)
6. Monitor Falco and metrics for anomalies
7. Full production rollout or rollback if needed

Prohibition: SSH into running container to apply patches, apt-get upgrade, yum update, etc. Rationale: Image-based upgrades are immutable, auditable, and reproducible; container patching is not. Enforcement: Admission control blocks containers with tools like apt, yum, apk package managers (optional stricter policy).

4.10 CleanSight Image Monitoring (Optional)

Requirement (Recommended): Deploy CleanSight for automated detection of outdated images.

What it does: Scans clusters for images older than X days and alerts on new upstream updates. Alert workflow.

1. CleanSight detects new image version available
2. Alert sent to engineering team
3. Engineering reviews SBOM and vulnerability diff
4. Team pulls new image and re-runs tests
5. Deployment follows standard process (staging → canary → prod) Configuration: Alert on images >30 days old (configurable). Enforcement: Optional but strongly recommended for regulatory compliance (PCI, SOC2 require documented patching process).

5. Exception Process

Policy exceptions are rare and subject to rigorous review.

5.1 When to Request an Exception

Valid reasons for exception: Vendor constraint (vendor only provides image from Docker Hub, no Cosign signing, etc.). Architectural necessity (e.g., proprietary kernel module requires specific Linux version). Third-party code (e.g., testing tools, observability agents not under our control).

Invalid reasons: "Too much work to migrate". "Vendor will update eventually". "Not a security issue in our environment".

5.2 Exception Request Process

1. Submit form to security@cleanstart.dev with: Image/workload name. Reason for exception. Duration requested. Risk assessment (what can go wrong). Proposed compensating controls. Cost/benefit analysis.
2. Triage (24 hours): Security team reviews completeness. Escalates to CISO if needed.
3. Review (3-5 business days): CISO and VP Engineering joint review. May request additional information. Risk assessment documented.
4. Decision: Approved: Documented in policy exception register; 90-day max initial term with renewal option. Approved with conditions: Compensating controls enforced. Denied: Rationale provided; team may appeal in 30 days with new evidence.
5. Monitoring: Exceptions reviewed monthly. Escalation if compensating controls fail or issue discovered. Automatic expiration after 90 days (requires re-approval).
6. Audit trail: All exceptions logged in compliance system for auditors

6. Policy Review and Updates

Annual review: Every March (or sooner if material security event occurs). Triggers for review: Breach or significant security incident New regulatory requirement (e.g., NIS2, SOC3) Major technology change (new container runtime, orchestrator, etc.) Audit findings or GRC team recommendation. Review process.

1. CISO convenes policy review committee (CISO, VP Eng, Compliance, SRE lead)
2. Review incidents, exceptions, audit findings from past year
3. Update SLAs, policies, enforcement mechanisms
4. Update risk register
5. Communicate changes to all teams
6. Update training materials Version control: Policy versions tracked; all changes approved by CISO.

7. Enforcement Mechanisms

7.1 CI/CD Pipeline Enforcement

All CI/CD jobs MUST include: Image scanning (Trivy or Snyk) with fail-on-Critical/High. SBOM generation and verification. Cosign signature verification. Admission control dry-run (simulate Kyverno/OPA policies). Artifact signing (Cosign).

Failure at any stage blocks image push to registry.

7.2 Kubernetes Admission Control

Kyverno Policies (Cluster-Wide)

require-image-registry: All images from approved registries only. require-cosign-signature: All images must be signed and valid. require-non-root-user: All containers runAsNonRoot=true, UID 65532. require-read-only-filesystem: All containers readOnlyRootFilesystem=true. require-capability-drop: All containers drop ALL capabilities. require-resource-limits: All containers have CPU/memory limits. prohibit-privileged: securityContext.privileged=true blocked. prohibit-host-networking: hostNetwork=true blocked.

OPA/Gatekeeper Policies (Governance)

no-high-vulnerability-images: Blocks deployment of images with Critical/High CVEs in active SLA window. require-labels: Deployments must have team, environment, compliance tags. require-network-policies: Workloads must have NetworkPolicy attached. require-pdb: Production workloads must have PodDisruptionBudget.

7.3 Audit and Logging

Kyverno violations: Logged and alerted; weekly report to GRC. Gatekeeper violations: Logged and escalated to CISO; exception tracking. Image signing events: Logged in audit trail (who, what image, when, key used). Remediation actions: Logged (e.g., image pulled, deployed, rolled back). Retention: Audit logs retained for 7 years (compliance requirement).

7.4 Runtime Monitoring

Falco eBPF rules monitor for: Containers attempting to modify root filesystem (write to /bin, /etc, /usr). Privilege escalation attempts (unshare, setuid/setgid, capset). Unexpected process execution (shell spawned in prod, unexpected binary execution). Network anomalies (unexpected outbound connections, port scanning). Suspicious file access (read sensitive files, write to audit logs).

Falco alerts trigger:

1. Real-time notification to SRE/CISO on-call
2. Automatic container isolation (network policies, traffic throttling)
3. Evidence preservation (container logs, network flows, process timeline)
4. Incident ticket creation in Jira
5. Escalation to incident response team if needed

8. Compliance Verification

8.1 Attestation and Proof

To demonstrate policy compliance to auditors:

Image Provenance: Cosign attestations prove: Image built by CleanStart (signed by organization key) Build parameters (Dockerfile, commit SHA, build time) Signed by authorized build service. SBOM Attestation: Cosign attestations prove: SBOM generated at build time (immutable) All dependencies enumerated Can be diffed between image versions. Deployment Logs: Kubernetes audit logs prove: Admission control policies enforced (all policies passed) Who deployed, when, with what image digest Image signature verified before admission. Scan Results: Vulnerability scan artifacts prove: Image scanned before deployment No Critical/High CVEs (or SLA active with exception) Scan timestamp, tool version, vulnerability database version.

8.2 Audit Collection Checklist

For compliance audits (SOC2, PCI-DSS, ISO 27001), provide:

[ ] Policy document (this file) and approval history. [ ] Kyverno/OPA policy rules and enforcement logs (monthly). [ ] RACI matrix and evidence of role fulfillment. [ ] CVE tracking sheet with SLA compliance (monthly). [ ] Exception register with approvals and reviews. [ ] Sample Cosign attestations (SBOM, signature). [ ] Sample Kubernetes audit logs (10 recent deployments). [ ] Falco alert logs (P1-P4 incidents, 12-month rolling). [ ] Training records (policy review, incident response, secure development). [ ] Incident reports from past 12 months with remediation evidence. [ ] CleanSight reports (image age distribution, update cadence).

8.3 Quarterly Compliance Review

GRC team reviews:

1. Metrics dashboard: CVE remediation SLA compliance %, exception count, Falco alert trend
2. Policy violations: Kyverno/OPA blocks, exceptions granted, exceptions expired
3. Audit findings: Any control gaps, remediation in progress
4. Risk register: New threats, control effectiveness, residual risk
5. Training: Team completion rates, policy awareness
6. Incident analysis: Trends, root causes, lessons learned

Output: Quarterly compliance report to executive team and Board (if required).

9. Definitions

Image: Container filesystem snapshot including application, dependencies, OS libraries. Signature: Cryptographic proof of image integrity and authenticity (via Cosign). SBOM: Machine-readable enumeration of all software components and dependencies. Vulnerability: Known security weakness (CVE) in software component. Remediation: Patching, updating, or removing vulnerable component. SLA: Service Level Agreement; deadline by severity for remediation. Admission Control: Kubernetes mechanism to enforce policies before workload deployment. Non-root user: User with UID ≥1000 (typical) or ≥65532 (unprivileged). Read-only root filesystem: Container root (/) mounted read-only; only /tmp and app dirs writable. Capability dropping: Removal of Linux kernel capabilities (e.g., CAP_SYS_ADMIN, CAP_NET_RAW). Attestation: Digitally signed metadata about an artifact (e.g., SBOM, scan results). Compensating control: Alternate security measure when primary control cannot be applied.

10. Approvals and Sign-Off

Appendix A: CVE Remediation SLA Reference

Critical Vulnerabilities (CVSS 9.0-10.0)

High Vulnerabilities (CVSS 7.0-8.9)

Medium Vulnerabilities (CVSS 4.0-6.9)

Low Vulnerabilities (CVSS 0.1-3.9)

END OF DOCUMENT