System-Level Flow

CleanStart is built on a verified source-to-production pipeline where every image flows through five stages in sequence. Each stage builds on the previous one, creating a comprehensive security framework that spans from initial compilation through continuous monitoring.

In Stage 1: Package Factory, hermetic builds compile source code from official repositories with full dependency resolution and security flags applied. The build environment is completely isolated from the internet and all dependencies are pre-fetched and verified before compilation begins.

Stage 2: Quality Gates validates images through a 78-test matrix, four-layer vulnerability detection, VEX attestation generation, and SLSA provenance creation. Every image must pass all gates before proceeding to the next stage.

Stage 3: Image Vault stores passing images in a secure OCI registry with complete verification artifacts including SBOMs, cryptographic signatures, and build attestations attached to each image. The vault is immutable, and all artifacts are tamper-proof.

Stage 4: Delivery distributes images across multiple registries and integrates them with CI/CD systems, orchestration platforms, and application deployments via standardized versioning schemes.

Stage 5: Continuous Verification implements a 24/7 monitoring system that correlates CVEs with deployed images, automatically triggers rebuilds when impacts are detected, and enforces compliance policies in real-time.

Stage 1: Package Factory

The Package Factory compiles images from source code using hermetic builds, forming the foundation of CleanStart's security posture.

Key Inputs

The Package Factory requires specific inputs to function correctly. YAML Config comes from the developer or from a template and declares image requirements like programming language, version, and packages needed. Source Repos are pulled from GitHub, official registries, and other canonical sources, providing the official source code for every package included in the image. Build Scripts come from the CleanStart framework and implement hermetic compilation and reproducible builds. Dependency Graph maintains a real-time index of 281 million dependencies with complete version resolution.

Compilation Process

The Package Factory implements four distinct steps. Source Verification downloads source from the official repository (GitHub, PyPI, crates.io, etc.), verifies cryptographic signatures where available, and confirms that the downloaded source matches the published release. Hermetic Build creates an isolated build environment where networking is disabled and no external resources can be accessed. All dependencies are pre-fetched and verified beforehand. Compilation flags are enforced for ASLR, stack canaries, and PIE. The complete build log is captured for reproducibility. Multi-Architecture Native Compilation separates the AMD64 build process (which runs on an AMD64 build node) from the ARM64 build process (which runs on an ARM64 build node). Cross-compilation is avoided entirely to prevent toolchain bugs. Both architectures are tested identically. Layered Output creates a development layer containing source code and build tools for analysis, a runtime layer with only compiled binaries, and a final OCI image in standardized format.

Example: Python 3.12 + FastAPI Image

The developer declares requirements in YAML specifying Python 3.12, FastAPI 0.104.1, Pydantic 2.5.0, and FIPS-compliant compilation. The Package Factory then resolves Python 3.12 source from the CPython repository and compiles it. FastAPI 0.104.1 is downloaded from PyPI, and its hash is verified. All transitive dependencies are resolved into a complete dependency graph. Python 3.12 is compiled with FIPS flags on the AMD64 build node. Python 3.12 is compiled with FIPS flags on the ARM64 build node. FastAPI and all dependencies are installed into the runtime layer. Final OCI images are created with both AMD64 and ARM64 variants.

Stage 2: Quality Gates

Before an image reaches the Image Vault, it passes through a complete quality assessment that evaluates security, functionality, and compliance.

Four-Layer Vulnerability Detection

Layer 1: Source Code Analysis parses source code into Abstract Syntax Trees to identify dangerous functions like strcpy and sprintf. Unsafe patterns are flagged, including hardcoded credentials and unvalidated input. Results are mapped to known vulnerability patterns for comparison with existing CVE databases.

Layer 2: Binary Analysis examines compiled ELF and Mach-O binaries to verify security flags like ASLR and stack canaries are present. Relocation information stripping is checked to prevent information disclosure. The presence of vulnerable symbols in compiled code is confirmed.

Layer 3: Runtime Reachability executes the image in an instrumented environment and tracks which functions are called during actual operation. Code paths that are never executed during normal operation are identified. Unreachable vulnerable code is marked as non-exploitable because it cannot be triggered in practice.

Layer 4: Usage Analysis examines application code if provided and determines which libraries and functions are actually called by the application. CVE scope is correlated to actual usage patterns. VEX attestations are generated that document whether vulnerabilities are exploitable, non-exploitable, or unknown based on actual usage.

78-Test Matrix

Every image is tested against a comprehensive suite of security, functionality, and performance tests. Security Tests cover 25 different areas including vulnerability scanning, FIPS validation, signature verification, cryptographic algorithms, and file permissions. Functionality Tests include 30 tests ensuring entrypoint execution, package imports, standard library availability, networking, and filesystem operations all work correctly. Performance Tests cover 15 metrics including boot time, memory usage, network latency, CPU efficiency, and scalability under load. Compliance Tests verify 8 areas including license verification, SBOM completeness, SLSA compliance, and signature validation.

Each test runs for both AMD64 and ARM64 architectures, resulting in 156 test runs per image variant (78 tests × 2 architectures). This ensures consistent behavior and security posture across both supported architectures.

SLSA Provenance Generation

Every image generates a SLSA Level 4 provenance document that cryptographically proves where the image came from and how it was built. The provenance includes the builder ID, source URI, build type, build configuration (like FIPS flag settings and target architectures), build invocation details, materials (source repositories and commits), and byproducts like the complete build log.

SLSA Level 4 guarantees that CleanStart provides include hermetic builds where the network is isolated during compilation, source provenance that is cryptographically linked to the source repository, build environment control through isolated build runners, and artifact verification where all outputs are signed and timestamped.

Stage 3: Image Vault

Once an image passes all quality gates, it is stored in the Image Vault with all verification artifacts attached and immutably sealed.

Storage Model

The Image Vault organizes images by name and architecture, with comprehensive verification artifacts attached to each variant. Under the image namespace (for example, python-fastapi:3.12), separate directories are created for AMD64 and ARM64 architectures. Each architecture directory contains the compiled OCI image (image.tar.gz) plus all verification artifacts: SBOMs in both CycloneDX and SPDX formats for supply chain transparency, SLSA v1.0 provenance attestations documenting build integrity, results from the complete 78-test suite, four-layer vulnerability analysis output, VEX attestations documenting exploitability status, cryptographic signatures proving image authenticity, and license compliance reports. Over 1,200 pre-built images are available in the vault, each with identical documentation and verification artifacts across both architectures.

Artifact Types Stored

The vault stores multiple artifact types to support different audiences and use cases. SBOM (CycloneDX) in JSON or XML format provides supply chain transparency for DevSecOps teams and auditors. SBOM (SPDX) in JSON or RDF format integrates with SPDX-compliant tools used by legal and compliance teams. SLSA Provenance in JSON-LD format serves as build integrity proof for compliance and forensics investigations. Build Log in text format provides the complete build transcript for debug and reproducibility purposes. Test Report in JSON captures 78-test results for quality assurance and security reviews. Vulnerability Report in JSON includes CVE analysis and scoring for security teams and incident response. VEX Attestation in JSON documents exploitability status for security teams. Signature in PEM format provides cryptographic proof for supply chain tools. License Report in JSON verifies OSS compliance for legal and procurement departments.

Multi-Registry Distribution

Images are automatically distributed to multiple registries for availability and redundancy. The Primary registry is hosted at CleanStart (https://registry.cleanstart.io). Public mirrors include Docker Hub, Quay.io, and GitHub Container Registry for maximum availability. Enterprise registries allow customers' private registries to be used via pull and push mechanisms. Artifact integrity ensures that the same SBOM, provenance, and signature exist in all registries, maintaining consistency across all distribution points.

Stage 4: Delivery

Images flow from the Image Vault into CI/CD systems, orchestration platforms, and production deployments through standardized processes.

CI/CD Integration

CleanStart integrates seamlessly into your existing CI/CD pipeline with eight consecutive verification steps. Step 1 occurs when the developer pushes code to the main branch. Step 2 has the CI/CD system (GitHub Actions, Cloud Build, or GitLab CI) automatically trigger build jobs. Step 3 resolves dependencies from the dependency index. Step 4 pulls CleanStart images with all verification artifacts (SBOM and provenance) included. Step 5 verifies image signatures and SLSA attestations before use. Step 6 checks SBOMs for license compliance against your organization's policies. Step 7 validates vulnerability reports to confirm no known CVEs are present. Step 8 deploys the verified image to production with full chain of custody.

This automated verification ensures every deployed image meets security and compliance requirements without manual intervention.

Version Management

Multiple versioning schemes are supported to meet different operational needs. Semantic versioning uses standard version numbers like python-fastapi:3.12.1. Digest-based pinning uses SHA256 hashes like python-fastapi@sha256:abcd1234... for maximum reproducibility. Security tag uses special tags like python-fastapi:3.12-latest-verified to mark verified images. Multi-architecture manifest allows a single tag to point to both AMD64 and ARM64 variants, simplifying orchestration.

Stage 5: Continuous Verification

After deployment, images are continuously monitored for new vulnerabilities that may emerge after initial release.

Real-Time CVE Correlation

The CleanStart Correlation Engine runs 24/7 to detect and respond to vulnerabilities immediately when they are published. When a new CVE is released, the engine performs four checks. Checks whether the CVE affects any tracked dependencies in your images. Identifies which images in your fleet contain the affected packages. Assesses severity by determining if the vulnerability is exploitable in your specific code paths (non-exploitable CVEs are marked appropriately via VEX attestations). Determines the optimal remediation path for your organization.

If a critical vulnerability is detected, the system automatically triggers a rebuild of affected images using patched source code. The complete 78-test suite runs on the rebuilt image for both AMD64 and ARM64 architectures. Fresh SLSA provenance attestations are generated to document the rebuild. All SBOMs and VEX attestations are updated with new vulnerability status. The updated image is deployed to production within 12-24 hours. An alert is sent to your security team with full context and remediation status.

Example: CVE-2024-1234 (Critical)

In a realistic scenario with a critical OpenSSL vulnerability (CVSS 9.5), the timeline proceeds as follows. At Hour 0 the CVE is published to NVD. By Hour 0.5 CleanStart automatically correlates the CVE to all affected images. At Hour 1 the automatic rebuild is triggered using OpenSSL 3.2 (patched version). By Hour 2 the 78-test suite runs on the new image variants. At Hour 4 the new image is published to the Image Vault with updated SBOM, SLSA provenance, and VEX attestations. Between Hour 12-24 the updated image is deployed to production registries and the security team is notified.

This represents a 12-24 hour vulnerability window compared to the 14-60 day industry standard for patches.

Threat Intelligence Feed

CleanStart maintains real-time visibility into multiple vulnerability sources. The NVD (National Vulnerability Database) tracks 14,000+ CVEs. GHSA (GitHub Security Advisories) provides 3,000+ GitHub-specific advisories. OSV (Open Source Vulnerabilities) offers project-specific vulnerability feeds. Proprietary research includes zero-day and early-stage vulnerability findings.

Each new vulnerability is automatically checked against all 1,200+ tracked images.

Data Flow: End-to-End Example

To understand how all five stages work together in practice, consider deploying a Python FastAPI microservice with guaranteed zero CVEs.

Step 1: Declare Requirements - The developer creates a YAML configuration file specifying Python 3.12, FastAPI 0.104.1, PostgreSQL driver (psycopg2), and FIPS security settings.

Step 2: Package Factory Compiles - The hermetic build automatically downloads CPython source code, verifies its cryptographic signature, compiles Python 3.12 with security flags, installs all dependencies, generates an SBOM, and compiles native binaries for both AMD64 and ARM64 architectures.

Step 3: Quality Gates - The image passes through a comprehensive 78-test matrix covering 25 security tests, 30 functionality tests, 15 performance tests, and 8 compliance tests. Four-layer vulnerability detection and SLSA provenance attestation generation occur automatically.

Step 4: Image Vault Storage - Once verified, the image is stored with 11 supporting artifacts: SBOM in CycloneDX and SPDX formats, SLSA Provenance v1.0, complete build log, test report, vulnerability report, VEX attestations, cryptographic signature, license report, and attestation bundle.

Step 5: Deploy - The CI/CD pipeline pulls the image along with its SBOM, verifies the image signature, validates SLSA provenance, checks license compliance, scans for the latest CVEs, and finally deploys to Kubernetes with full verification.

Step 6: Continuous Verification - A 24/7 monitoring system correlates new CVEs in real-time, automatically triggers rebuilds when needed, maintains a 12-24 hour remediation SLA, and continuously monitors compliance status.

Key Architectural Principles

CleanStart's design is guided by five fundamental principles that work together to create a secure, reproducible, and maintainable container supply chain.

1. Hermetic Builds

Hermetic builds ensure total reproducibility through network-isolated compilation. All dependencies are pre-fetched before compilation begins, guaranteeing that the build will produce the same binary every single time given the same inputs. No surprise updates or patches are introduced because external resources cannot be accessed during the build.

2. Source-First

Rather than starting with pre-built binaries, CleanStart compiles everything from official source code. The source is cryptographically verified before compilation begins. Every compilation flag is under your control, allowing customization for security (FIPS mode, hardening) or performance (optimization levels).

3. Verification-by-Design

Verification is not a scanner bolted onto an existing system after the fact. Four-layer detection is baked directly into the pipeline as a core requirement. Eleven artifact types prove security rather than merely asserting it—every claim is backed by cryptographic signatures, test results, and provenance records.

4. Automated Remediation

CVEs are detected and remediated automatically through real-time correlation. Rebuilds happen automatically when vulnerabilities affect your images. Remediation completes within a 12-24 hour SLA. Zero-CVE guarantees are maintained through continuous monitoring that never stops.

5. Multi-Architecture Native

Rather than using cross-compilation, each architecture gets its own native build on appropriate hardware. AMD64 compilation happens on AMD64 nodes. ARM64 compilation happens on ARM64 nodes. Identical testing ensures both architectures have identical security posture and functionality.

Next Steps

Build your first image: Check the Quick Start guide. Understand the four layers: Review Deep Code Analysis Overview. Configure images declaratively: See YAML Image Configuration. Review compliance: Read the Container Security Maturity Model.