Rebuilding Compliance Evidence from Build Artifacts
Most organizations approach compliance as an afterthought: build the system, then add audit controls, documentation, and certifications. This reactive approach creates gaps, misaligns engineering and compliance, and costs 3-5x more than building security in from the start.
CleanStart implements reconstructive compliance: security requirements are embedded in the product architecture itself, making compliance automatic and continuous rather than manual and periodic.
Additive vs. Reconstructive Compliance
Additive Compliance (Traditional)
Traditional Approach: Build the system (6 months), then identify compliance gaps (2 weeks), add audit controls (4 weeks), add monitoring (3 weeks), document controls (2 weeks), and finally conduct third-party assessment (4 weeks). Total time: 26 weeks with high rework cost, remaining gaps, and team distraction.
Reconstructive Compliance (CleanStart): Design with compliance in mind (2 weeks) while building with built-in controls, ensuring compliance is continuous and assessment is verification only. Artifacts automatically generate compliance evidence. Third-party assessment becomes verification rather than discovery. The system is FedRAMP/ISO/SOC 2 ready at deployment time. Total time: 8 weeks with minimal rework, no gaps, and team alignment on requirements.
Compliance-First Architecture
The following diagram illustrates the additive vs. reconstructive compliance approaches and timeline:
graph TD A["Development<br/>Project Start"] -->|Traditional<br/>Additive| B["Build System<br/>6 months"] A -->|CleanStart<br/>Reconstructive| C["Design with<br/>Compliance in Mind<br/>2 weeks"] B -->|Gap| D["Identify<br/>Compliance Gaps<br/>2 weeks"] C -->|Built-in| E["Build with<br/>Controls<br/>4 weeks"] D -->|Retrofit| F["Add Audit<br/>Controls<br/>4 weeks"] E -->|Automatic| G["Compliance Evidence<br/>Automatically<br/>Generated"] F -->|Add| H["Add Monitoring<br/>3 weeks"] G -->|Ready| H2["Ready for<br/>Assessment<br/>8 weeks total"] H -->|Document| I["Document<br/>Controls<br/>2 weeks"] I -->|Assess| J["Third-Party<br/>Assessment<br/>4 weeks"] J -->|Result| K["FedRAMP/ISO/SOC2<br/>Certified<br/>26 weeks total"] H2 -->|Assess| L["Third-Party<br/>Verification Only<br/>2 weeks"] L -->|Result| M["FedRAMP/ISO/SOC2<br/>Ready<br/>10 weeks total"] K -->|Timeline| K1["26 weeks<br/>High rework<br/>Gaps remain<br/>Team distracted"] M -->|Timeline| M1["10 weeks<br/>Minimal rework<br/>No gaps<br/>Team aligned"] K1 -->|Total Cost| K2["3-5x more<br/>expensive"] M1 -->|Total Cost| M2["Efficient<br/>Integrated"] style B fill:#ffcccc style C fill:#ccffcc style K fill:#ff9999 style M fill:#99ff99 style K2 fill:#ff6666 style M2 fill:#66ff66SLSA and Provenance as Core Features
Rather than adding SLSA verification after the fact, CleanStart makes SLSA Level 4 the only way to build:
# All builds are SLSA Level 4 by defaultcleanimg-init --build --image myapp:1.0.0# ✓ Hermetic build environment# ✓ Signed provenance (SLSA)# ✓ Automatic transparency log entry# ✓ Reproducible build verification# Result: Compliance evidence generated automaticallyNo additional configuration, no special flags, no "compliance mode." Every build automatically produces FedRAMP SI-2 evidence (supply chain security).
VEX as Standard Output
Rather than treating VEX as optional, CleanStart generates context-aware VEX for every scan:
# Scanning automatically generates VEXcleanimg-init --scan --image myapp:1.0.0 --output-vex report.vex# Output includes:# - Vulnerability status for every CVE (not_affected/affected/fixed)# - Justifications for risk acceptance decisions# - Impact statements for compliance reviews# - Audit trail of assessmentThis satisfies NIST 800-53 SI-4 (Vulnerability Monitoring) and EU CRA requirements without additional steps.
In-Toto Links as Workflow Artifacts
Supply chain verification is built into the CI/CD pipeline:
# Standard GitHub Actions workflowjobs: build: steps: - uses: cleanstart/build-attest@v2 # Generates In-Toto link automatically # Each step creates verifiable evidence # Layout compliance checked before deploymentNo custom attestation tools needed. Standard workflow → compliant evidence.
Compliance Through Immutable Architecture
Immutable Build Artifacts
All build outputs are content-addressed (identified by hash):
# Image is identified by its hash, not just a taggcr.io/apk-test-442304/myapp@sha256:abc123def456... # Hash uniquely identifies:# - Exact source code (git commit)# - Build environment and tools# - Base image and all dependencies# - Build configuration # If anything changes, hash changes# Immutable reference enables auditingThis satisfies CM-3 (Change Control) and SC-3 (Security Functions) by making tampering detectable.
Cryptographic Link Integrity
Every stage cryptographically links to previous:
Source Code (signed commit) ↓ hash matches provenanceBuild (SLSA provenance) ↓ hash matches SBOMSBOM (signed attestation) ↓ hash matches scanScan (vulnerability report) ↓ hash matches VEXVEX (signed) ↓ hash matches policy evalPolicy (passed/failed) ↓ hash matches deploymentKubernetes (audit logged)Break any link, entire chain is invalid. Perfect auditability.
Risk-Based Vulnerability Management
Automatic VEX Status Determination
Rather than manual triage, CleanStart uses code analysis to determine exploitability:
# CleanStart analyzes:# 1. Static code: Is vulnerable function present in binary?# 2. Data flow: Can attacker control inputs to vulnerable code?# 3. Configuration: Does runtime config prevent exploitation?# 4. Privilege: What privilege level required? # Example:# CVE-2024-5678: RCE in OpenSSL certificate parsing# Analysis: Function present, but never called (no TLS parsing)# VEX Status: not_affected (vulnerable_code_not_in_execute_path)# Compliance: Risk accepted due to technical evidence, not risk appetiteThis satisfies RA-3 (Risk Assessment) with technical evidence rather than opinion.
Continuous Compliance Verification
Real-Time Compliance Posture
Compliance status is continuously updated:
# Get current compliance posturecleanimg-init --compliance-status --image myapp:1.0.0 # Output shows:# SLSA Level 4: ✓ PASS (provenance verified)# SBOM Present: ✓ PASS (signed SPDX 3.0)# Vulnerability Assessment: ✓ PASS (VEX status for all CVEs)# Approved Base Image: ✓ PASS (whitelist verified)# No Critical Vulns: ✓ PASS (0 unresolved critical)# Signature Valid: ✓ PASS (Sigstore verified)# FedRAMP Ready: ✓ PASS (all SI-2 controls satisfied) # Can deploy with confidence# Can generate compliance report at any time (not quarterly)No manual compliance reviews. Compliance is a measurable, continuous property.
Compliance Dashboards
Real-time visibility into compliance posture across all deployments:
# Get fleet-wide compliance viewkubectl get images --compliance-status # Output:# IMAGE VERSION SLSA SBOM VEX SIGATURE FEDRAMP# myapp 1.0.0 L4 ✓ ✓ ✓ READY# my-database 2.1.3 L4 ✓ ✓ ✓ READY# analytics-service 0.8.1 L3 ✓ ✓ ✗ NEEDS-SIGN# legacy-worker 1.0.0 L1 ✗ ✗ ✗ FAIL # Identify non-compliant workloads# Remediate automatically or alertCompliance as Code
Policy Enforcement in CI/CD
# compliance.rego - OPA policy as codepackage deployment # FedRAMP SI-2 Controlsrequire_slsa_provenance { input.image.provenance.level >= 4} require_sbom { input.image.sbom.format == "spdx-3.0"} require_vulnerability_assessment { count(input.image.vulnerabilities) == 0 # or count(input.image.vex.affected) == 0} require_signature { input.image.signature.valid == true input.image.signature.signer in approved_signers} # ISO 27001 A.14.2 Secure Developmentrequire_secure_build { input.image.build.environment == "isolated" input.image.build.tool in approved_tools} # Deploy only if all policies passallow { require_slsa_provenance require_sbom require_vulnerability_assessment require_signature require_secure_build}Deployment fails if any policy is violated:
# Deploy triggers policy checkkubectl apply -f deployment.yaml # Admission controller runs compliance policies# If any fail, deployment is rejected# No human approval needed (policies are human-approved)Compliance Evidence Generation
Automatic Audit Trail
Every action creates immutable compliance evidence:
# Build creates multiple compliance artifactscleanimg-init --build --image myapp:1.0.0 # Artifacts created:# 1. SLSA provenance (SI-2: Supply chain security)# 2. SBOM (SI-2: Software composition)# 3. Build log (AU-2: Audit trail)# 4. Image signature (SC-7: Cryptographic protection)# 5. Base image attestation (CM-5: Change control) # All artifacts are cryptographically signed# All stored in tamper-proof registry# All accessible for compliance reviewCompliance Report Generation
# Generate FedRAMP compliance reportcleanimg-init --compliance fedramp \ --image myapp:1.0.0 \ --output compliance-report.json # Report includes:# - Mapping to all 421 FedRAMP High controls# - Evidence from SLSA, SBOM, VEX, signatures# - Audit trail of all changes# - Risk assessment with VEX status# - Remediation timeline for affected vulnerabilities # Can be submitted directly to compliance reviewers# No manual gathering of evidence neededCost Benefits of Reconstructive Compliance
Time Savings
Activity | Additive | Reconstructive |
|---|---|---|
Initial compliance assessment | 4 weeks | 1 week (validation only) |
Quarterly compliance reviews | 3 weeks each | 1 day (automated verification) |
Remediation of compliance gaps | 4 weeks | Automatic (built-in) |
Audit preparation | 2 weeks | 2 days (evidence already ready) |
Third-party assessment | 4 weeks | 2 weeks (verification only) |
Total First Year | 26 weeks | 8 weeks |
Reduced Rework
With reconstructive compliance, you achieve zero compliance gaps (built-in, not bolted-on), zero duplicate controls (single source of truth), zero evidence gathering (automatic artifacts), and zero surprise audit findings (continuous verification).
Compliance-Driven Development
Developers Write Compliant Code Automatically
# Developers use standard CleanStart toolscleanimg-init --build --image myapp:1.0.0cd src && git commit -m "Add feature X"cleanimg-init --scan --image myapp:1.0.0# All compliance controls are satisfied by defaultNo special "compliance mode," no compliance training needed, no extra burden.
Compliance Team Shifts to Verification
Rather than policing, compliance team verifies that built-in controls are working:
# Compliance review is automatedcleanimg-init --audit-trail --from="2025-09-01" --to="2025-10-04" # Output shows:# - 247 builds executed# - 247 SLSA Level 4 provenances generated# - 0 builds without provenance (100% compliance)# - 0 images deployed without approval# - 0 vulnerability assessment gaps # Compliance team reviews summary# Audit is done in hours, not weeksFedRAMP Compliance Example
Traditional Path
1. Initial consultation: 4 weeks2. Document system description: 3 weeks3. Develop security controls: 8 weeks4. Implement controls: 8 weeks5. Audit implementation: 4 weeks6. Remediate findings: 4 weeks7. Final assessment: 2 weeksTotal: 33 weeks, $150K-300KReconstructive Compliance Path
1. Initial consultation: 1 week (CleanStart architecture already FedRAMP-ready)2. Validate controls are implemented: 2 weeks3. Collect compliance evidence: 1 week (SLSA, SBOM, VEX, signatures already generated)4. Submit for assessment: 1 week5. Third-party assessment: 2 weeks (Verification only, no major gaps)6. Final approval: 1 weekTotal: 8 weeks, $30K-50KImplementing Reconstructive Compliance
Phase 1: Architecture Review (1 week)
Map requirements to built-in controls. Identify any custom compliance needs. Design policy-as-code policies.
Phase 2: Tool Integration (1 week)
Deploy CleanStart scanning. Configure CI/CD compliance checks. Set up compliance dashboards.
Phase 3: Evidence Verification (2 weeks)
Verify SLSA provenance generation. Test VEX status determination. Validate signature verification.
Phase 4: Compliance Assessment (2 weeks)
Review generated compliance artifacts. Validate control effectiveness. Document compliance posture.
Phase 5: Continuous Monitoring (Ongoing)
Real-time compliance dashboards. Automated remediation of gaps. Quarterly compliance updates.
See Also
VEX Documents: vex-documents.md — Context-aware vulnerability status. SBOM: spdx-sbom.md — Software composition evidence. SLSA Level 4: slsa-level-4.md — Build integrity assurance. FedRAMP High: ../regulatory/fedramp-high.md — Compliance control mapping.