Knowledge Hub

Reconstructive Compliance: Building Security Into the Product

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:#66ff66

SLSA 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 automatically

No 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 assessment

This 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 deployment

No 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 auditing

This 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 appetite

This 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 alert

Compliance 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 review

Compliance 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 needed

Cost 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 default

No 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 weeks

FedRAMP 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-300K

Reconstructive 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-50K

Implementing 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.