Document Version: 1.0 Last Updated: March 22, 2026 Audience: Security architects, compliance teams, auditors Purpose: Bridge foundational concepts (01-understand) with detailed control mappings (07-secure)

Compliance as Architecture: Embedding Controls Into the Build Pipeline

CleanStart doesn't treat compliance as a post-deployment checklist. Compliance controls are embedded into the build process itself, turning the pipeline into a compliance engine that generates evidence automatically.

Key thesis: Compliance is not bolt-on. It's architectural.

The traditional approach to compliance involves building a container image, deploying to production, then months later being asked during audit season to prove the image was built securely. This creates a compliance crisis where you must scramble to find build logs, reconstruct approvals, manually create software bills of materials, track patch history, and implement image signing retroactively. The result is often audit failure or massive remediation work.

CleanStart's approach is fundamentally different: design architecture with compliance controls as first-class citizens, automatically generate compliance evidence at every build (SBOMs, signatures, attestations), verify compliance at deployment time with admission control, and transform audit from evidence creation into evidence review.

This deep-dive shows how each architectural decision in CleanStart maps to specific compliance control requirements across SOC 2, ISO 27001, PCI-DSS, HIPAA, and FedRAMP frameworks.

Part 1: The Compliance Challenge in Traditional Container Security

The Problem: Post-Hoc Compliance

Organizations following traditional container security practices face a cyclical challenge. During the build phase, developers create Dockerfiles and run basic security scans. During deployment, images are pushed to the registry and deployed to Kubernetes. Then six months later during the audit phase, auditors ask "Can you prove this image was built securely?" This triggers an evidence collection crisis: Where is the build log? Who approved the changes? What dependencies are in this image? Has this image been patched? Is this image signed? The typical result is either audit failure or massive remediation work.

The CleanStart Solution: Evidence-Generating Architecture

CleanStart's architecture makes compliance inevitable—not optional. The traditional approach involves just a Dockerfile and image, with evidence creation being manual and taking weeks of work. The CleanStart approach involves a Dockerfile feeding into a pipeline that produces 11 artifacts plus the image, with evidence creation being automatic per build. Traditional deployment requires trusting that the image is good, while CleanStart uses admission control to verify six compliance properties. Traditional audit becomes a search for evidence, but CleanStart audit becomes evidence review. Compliance risk in traditional systems is high due to evidence gaps, while CleanStart has low risk since evidence is automatic.

Part 2: CleanStart's Security Architecture (Compliance View)

The following diagram shows how CleanStart's build pipeline automatically generates compliance evidence at each stage:

1Source Stage2Build Stage3Hardening Stage4Scanning Stage5Signing Stage6Evidence ArtifactsSBOMSPDX + CycloneDX7Audit/Compliance

The Build Pipeline as a Compliance Engine

Each stage of CleanStart's build pipeline generates compliance evidence through deliberate architectural design. The build pipeline consists of seven sequential stages that together form a compliance engine.

Stage 1: Source Verification requires Git signed commits using GPG or SSH, enforces branch protection with code review via CODEOWNERS, and records commit hashes in provenance attestations. This produces source integrity evidence.

Stage 2: Deterministic Compilation ensures the same source code and build environment always produce the same image hash. Build parameters are captured as reproducibility evidence. The build is executed in an isolated GCP Cloud Build container with no persistent build state, meeting SLSA Level 4 requirements. This produces build integrity evidence plus SLSA Level 4 provenance.

Stage 3: Package Assembly & SBOM Generation identifies all dependencies in a transitive graph. SBOMs are created in both SPDX 3.0 (industry standard) and CycloneDX 1.4 (developer-friendly) formats. Checksums and provenance links are included for each component. This produces a Software Bill of Materials in two formats.

Stage 4: Image Hardening & Security removes the shell (/bin/sh) to create a shell-less container. The root filesystem is made read-only to prevent persistent state changes. The container runs as a non-root user (UID 65532). A minimal base image (Alpine or distroless) is used. CIS benchmark scanning and remediation are performed. This produces a hardened image plus CIS compliance evidence.

Stage 5: Vulnerability Scanning & Verification runs a 78-test inspection suite on every image. Security properties are verified (shell-less, filesystem permissions, user privileges). SBOM completeness is verified. Signature attestations are validated. Vulnerability scanning is performed, blocking release for critical vulnerabilities. This produces test results and scan evidence.

Stage 6: Cryptographic Signing & Attestation signs the image with Cosign using ECDSA or RSA-4096. A SLSA provenance attestation is appended. Build log attestations document all steps. In-Toto supply chain metadata is included. A VEX document documents vulnerability exploitability. This produces a signed image plus five attestation types.

Stage 7: Registry Publication & Custody pushes the image to registry.cleanstart.com. All 11 artifacts are stored in the registry. Immutable image tags prevent overwrites. RBAC controls govern registry access. Audit logs document all registry operations. Optional monitoring via CleanSight is available. This produces an auditable registry with the complete provenance chain.

The 11 Verification Artifacts

Every image release produces 11 distinct compliance artifacts, each serving specific compliance purposes:

The Cosign Signature provides image authenticity and integrity, serving SOC 2 CC8, ISO A.8.25, PCI Req 6.3, and FedRAMP CM-14. SBOM in SPDX 3.0 format provides complete component inventory with relationships, serving SOC 2 CC3.2, ISO A.8.28, PCI Req 6.3.2, and HIPAA §164.312(b). SBOM in CycloneDX 1.4 format provides alternative BOM format with vulnerability data, serving the same frameworks as SPDX 3.0. SLSA Provenance at Level 4 provides proof that the build was secure and traceable, serving SOC 2 CC8.1, ISO A.8.25, PCI Req 6.3, and FedRAMP SA-10. Build Log Attestation documents step-by-step build execution, serving SOC 2 CC4.1, ISO A.8.29, and PCI Req 11.

Vulnerability Scan Results identify known CVEs in image components, serving SOC 2 CC4.1, ISO A.8.29, and PCI Req 6.2. CIS Benchmark Scan provides container hardening compliance validation, serving SOC 2 CC6, ISO A.8.9, and PCI Req 2.2. Package Verification Hashes verify dependency integrity via SHA-256, serving SOC 2 CC5.1, ISO A.8.25, and PCI Req 6.3. Source-to-Image Mapping documents the Git commit to container mapping, serving SOC 2 CC8.1, ISO A.8.25, and FedRAMP CM-3. Dependency Tree Attestation documents the transitive dependency graph, serving SOC 2 CC3.1 and ISO A.8.28. FIPS 140-3 Certificate provides cryptographic module validation, serving SOC 2 CC6.7, ISO A.8.24, PCI Req 4, HIPAA §164.312(e), and FedRAMP SC-13.

Key Point: A single image pull from the registry gives you all 11 artifacts. Compliance evidence is built-in, not retrofitted.

Part 3: Framework-Specific Compliance Mappings

CleanStart's technical controls map directly to requirements in major compliance frameworks. Shell-less images, read-only filesystems, and non-root execution form the foundation of container hardening across SOC 2, ISO 27001, PCI-DSS, HIPAA, and FedRAMP. SBOM generation, SLSA provenance attestations, and image signing together provide complete supply chain evidence. Continuous vulnerability scanning, comprehensive testing suites, and admission control enforcement create continuous compliance verification. These controls work together to create a comprehensive compliance program that addresses requirements across multiple frameworks simultaneously.

Part 4: Multi-Framework Synthesis

Key insight: The same technical controls often satisfy multiple frameworks simultaneously. Shell-less, read-only, and non-root enforcement satisfies controls from SOC 2, ISO, PCI, HIPAA, and FedRAMP. This means investing in comprehensive supply chain automation provides compliance benefits across multiple frameworks.

Part 5: Beyond Technical Controls

Compliance requires technical controls, policies, incident response, training, and audit procedures working together to create a comprehensive program. Technical controls alone are insufficient—you need documented policies explaining what images are allowed, procedures for incident response when vulnerabilities are discovered, training for developers on secure development practices, and regular audits to verify controls are working.

Part 6: What to Read Next

Deep-Dive Documentation

Related deep-dives in 02-explore/deep-dives include the 11 Verification Artifacts, Two-Factory Architecture, Zero-Trust Supply Chain, and Stage 0 Compiler Bootstrap documentation.

Compliance Control Mappings (07-secure/compliance)

For specific frameworks, see SOC 2 Type II Mapping, ISO 27001 Mapping, and PCI-DSS Mapping documentation.

Hardening & Implementation (07-secure)

For deployment details, see CIS Hardening Guide, Admission Control Policies, Image Signing, and SBOM Generation documentation.

Regulatory & Standards (07-secure/regulatory)

For government and enterprise requirements, see FedRAMP High Readiness and EU AI Act & CRA documentation.

Foundational Concepts (01-understand)

If you're new to compliance frameworks, see What is Supply Chain Security?, What is Compliance as Code?, What is FIPS?, and What is SLSA? documentation.

Compliance Approaches: Alternatives to Automated Supply Chain

Multiple approaches exist for achieving container compliance. Manual compliance assembly involves conducting security scanning, writing documentation, and assembling audit evidence manually for each image release. Its advantages include complete control and compatibility with any tooling, but disadvantages include time consumption, error-proneness, poor scalability to large image fleets, and incomplete or outdated evidence.

Vulnerability scanning only uses automated vulnerability scanners like Trivy, Grype, or Snyk to identify CVEs in container images without other evidence collection. Advantages include catching known vulnerabilities and minimal tooling overhead, but disadvantages include lack of provenance information, no proof of build integrity, and insufficiency for most compliance frameworks.

Image signing without full supply chain uses container image signing with Cosign or Notary to verify authenticity without capturing full build evidence. Advantages include prevention of tampering in transit and simpler implementation than full supply chain, but disadvantages include failure to prevent compromised builds and lack of visibility into image contents or dependencies.

Partial automation with cloud-native services uses cloud build services like Google Cloud Build or AWS CodePipeline which provide some logging and evidence but require additional manual controls for compliance. Advantages include built-in isolation, automatic logging, and platform integration, but disadvantages include vendor lock-in, possible incompleteness with specific compliance requirements, and need for additional configuration.

Full supply chain automation implements comprehensive tooling for automated evidence generation including SBOM creation, SLSA attestations, continuous vulnerability scanning, and signature verification at deployment. Advantages include complete compliance evidence, scalability, repeatability, and audit-readiness, but disadvantages include significant tooling overhead, learning curve, and requirement for security engineering effort.

The choice depends on your compliance requirements, image fleet size, and security engineering resources available.

Appendix: Quick Reference — Industry Compliance Coverage

By Framework

By Control Type

End of Document

Document Changelog