Background: For a foundation on how container images are structured, see Container Image Fundamentals and Image Layers Deep Dive.

The Separation of Concerns

CleanStart Source Intelligence Core's architecture rests on a fundamental principle: separate the building of packages from the composition of container images.

In the traditional approach, package building and image composition are tightly coupled. A developer commits code, CI/CD runs build commands like mvn, cargo, or npm to produce a binary, a Dockerfile creates an image from that binary, and the registry stores the result. This coupling creates several problems: package building and image composition logic become intertwined, there is no separation of concerns between the two processes, and vulnerabilities in packages propagate directly to all downstream images without independent verification.

CleanStart separates these concerns into two independent factories. Factory 1, the Package Factory, handles all dependencies including npm packages, Maven artifacts, Python wheels, Go binaries, and Rust crates—resolving and verifying each one to produce signed, verified packages. Factory 2, the Image Vault, consumes only those verified packages from Factory 1, assembles container images, applies distroless security hardening, and signs the final images for distribution.

This separation enables multiple important benefits. Packages can be verified independently from image building, reducing the build time for new images that reuse existing packages. Packages become reusable across multiple images without requiring rebuilds, saving significant computational resources. Different security policies can be applied per image without affecting other images in the system. And builds can proceed in parallel without one blocking another, enabling efficient scaling.

Factory 1: Package Factory

The Package Factory is responsible for resolving, verifying, and building all dependencies.

What Goes In

The Package Factory accepts raw dependencies from a diverse ecosystem of package sources, each with their own distribution mechanisms and registries. NPM packages come from the NPM registry (npm.org), representing the JavaScript and TypeScript ecosystem. Python packages are sourced from PyPI (the Python Package Index), providing the foundation for Python-based applications. Maven artifacts arrive from Maven Central and other Maven repositories, supporting Java and JVM-based languages. Go modules are specified in go.mod files and fetched from various Go module proxies. Rust crates are sourced from crates.io, the official Rust package registry. System libraries come from package managers like apt for Debian/Ubuntu systems and yum for RHEL/CentOS systems. Finally, the Linux kernel itself can be a dependency for performance-critical systems or custom configurations. This diversity of sources makes dependency verification and management exceptionally complex, yet the Package Factory handles all of it through a unified verification pipeline that ensures consistent security standards across all dependency types.

Verification Process

For each dependency entering the Package Factory, a comprehensive multi-step verification process ensures authenticity, security, and compatibility before the dependency is approved for use. The process begins with fetching source code directly from upstream repositories like GitHub or the official project repositories, establishing a direct chain back to the source. The factory then verifies cryptographic signatures—GPG signatures for many packages, code signing certificates for others—proving that the code came from the legitimate maintainer and wasn't tampered with during transit. Vulnerability scanning follows, comparing the source code against authoritative vulnerability databases including the NVD (National Vulnerability Database), GHSA (GitHub Security Advisories), and OSV (Open Source Vulnerabilities). Transitive dependency analysis examines the complete dependency tree, recursively analyzing every package that the original dependency depends on, and every package those depend on, ensuring that no hidden vulnerabilities exist in indirect dependencies. Compatibility testing involves integration testing the package alongside other common packages it typically works with, catching version conflicts and integration issues before they manifest in production. The factory builds the package from source using a verified and hardened toolchain, ensuring reproducibility and preventing supply chain attacks through pre-built binaries. Finally, the resulting artifact is signed with the Package Factory's cryptographic key, proving the factory has verified and approved this specific version.

What Comes Out

The Package Factory outputs comprehensively verified and documented packages, each accompanied by a complete dossier of metadata proving its provenance and security posture. Consider express@4.18.2 as an example. The output includes a source code hash (abc123...) that uniquely identifies the exact source code used, computed over the entire source tree. A binary hash (def456...) uniquely identifies the compiled package. A CycloneDX JSON SBOM (Software Bill of Materials) documents all components contained in the package with precise version information. A SLSA L4 attestation provides cryptographic proof of how the package was built, what inputs were used, and who performed the build. A Cosign signature ensures the authenticity of all the above metadata. And a complete list of known vulnerabilities relevant to this package version (for example, CVE-2024-1234) provides security context. Every single package—whether it's express@4.18.2, pg@8.9.0, or lodash@4.17.21—receives this same comprehensive, standardized metadata treatment. This ensures that all downstream consumers have consistent, machine-readable security information about every dependency.

Each package output by the Package Factory carries multiple critical guarantees: it is cryptographically signed, proving the factory has verified it. It is attested with full provenance information, creating an audit trail of how it was built. It is scanned for vulnerabilities, documenting known security issues. And it is indexed for rapid lookup, enabling quick discovery and verification by the Image Vault.

Package Factory Workflow

When a developer declares dependencies, the Package Factory receives the dependency list and begins a comprehensive verification process. It fetches source code directly from the repository and verifies git signatures to ensure the code came from the maintainer. It scans the code against the NVD (National Vulnerability Database), GHSA (GitHub Security Advisory), and OSV (Open Source Vulnerabilities) databases. It resolves the full transitive dependency tree, computing all indirect dependencies. It detects conflicts and checks for version incompatibilities that might cause issues.

The factory then builds the package from source using a verified toolchain, generating a binary artifact. It creates comprehensive metadata: an SBOM in both SPDX and CycloneDX formats for complete inventory, SLSA L4 attestations with In-Toto provenance, and cryptographic signatures. Integration tests are run to confirm the package works correctly. Finally, the verified, signed package is stored in the Package Factory index, ready for use in any image that needs it.

Factory 2: Image Vault

The Image Vault is responsible for assembling container images from verified packages.

What Goes In

The Image Vault receives inputs from multiple sources: verified packages from Factory 1, application source code, security policy definitions, Kubernetes manifests, and configuration files.

Image Assembly

The Image Vault's assembly process for each application follows a rigorous, multi-step procedure designed to ensure security, testability, and consistency. First, the factory selects a base image from a curated set of verified, minimal base images—typically distroless images that provide the absolute minimum OS functionality required to run the application. The factory then copies verified packages only from Factory 1, ensuring that no dependencies are sourced from untrusted registries. The application is compiled using verified build tools, creating the application binary that will actually run in the image. The complete test suite is executed against the compiled application—unit tests verify application logic, integration tests confirm interaction with real dependencies, and security tests verify that the application doesn't have obvious security flaws. Build artifacts are generated: a comprehensive SBOM documenting every dependency in the image, SLSA L4 attestations proving how the image was built and by whom, a VEX (Vulnerability Exploitability) document assessing which known vulnerabilities actually pose a risk in this specific image context. Security hardening is applied at the image level, enforcing a read-only root filesystem, removing all shell access, and dropping all unnecessary privileges. The resulting image is signed with the Image Vault's deployment key, creating an artifact that can be verified at deployment time. Finally, the signed image is stored in the secure vault registry, with access controls ensuring only authorized parties can retrieve it.

What Comes Out

The Image Vault produces a complete container image in OCI format with a specific digest (sha256:abc123...). The image consists of multiple layers: a distroless base layer providing minimal OS functionality, a package layer containing all dependencies from Factory 1, an application layer with the compiled application code, and a configuration layer with runtime settings.

The image includes comprehensive metadata: a complete SBOM documenting every package in the image, attestations proving who built the image and how, a VEX (Vulnerability Exploitability) document assessing which vulnerabilities actually pose a risk in this context, a cryptographic signature proving the image came from the Image Vault, and a Helm chart specifying how to deploy the image.

Security properties are enforced at the image level: no shell access (neither bash nor sh), read-only root filesystem preventing runtime modifications, runs as a non-root user, and includes only the minimal dependencies actually needed to run the application.

Image Vault Workflow

When a developer submits a Dockerfile, the Image Vault receives the request and begins a comprehensive build and hardening process. It validates the Dockerfile syntax and policies, selects a verified base image, and fetches packages directly from Factory 1 (not from public registries). The application is then built using multi-stage builds to separate compilation from runtime, pruning unnecessary dependencies, and applying security hardening.

The image is tested at multiple levels: unit tests verify application logic, integration tests confirm interaction with real dependencies, security scans identify vulnerabilities, and compatibility tests ensure it works across different environments. Artifacts are generated: an SBOM for complete package inventory, SLSA L4 attestations proving provenance, a VEX document assessing vulnerability exploitability, a Helm chart for Kubernetes deployment, and the OCI image itself.

The image is then signed using the Image Vault's signing key, stored in the secure vault, and a reference is returned to the developer. The result is a verified, signed, hardened container image ready for deployment.

Inter-Factory Verification

The two factories communicate through cryptographic signatures that verify artifact authenticity at every step. Factory 1 (the Package Factory) produces verified packages and signs them with its signing key, storing the signed packages in the package registry. Factory 2 (the Image Vault) then verifies each package's signature using the Package Factory's public key before incorporating it into an image. When Factory 2 generates an image, it includes package provenance information and signs the complete image with the Image Vault's signing key.

Finally, when deployment infrastructure attempts to deploy the image, it verifies the image signature using the Image Vault's public key. The deployment only proceeds if all signatures are valid, creating an unbroken chain of cryptographic verification from source code through packaging to deployment.

Dependency Updates

When an upstream dependency releases a new version—for example, a security patch to OpenSSL 1.1.1x—the two-factory architecture enables rapid, coordinated updates. Factory 1 detects the new version, fetches it, verifies the maintainer's signatures, scans it against vulnerability databases, tests compatibility with dependent packages, and builds the package from source.

Once Factory 1 completes verification, it produces a new signed and attested package, marks all previous vulnerable versions as unsafe in metadata, and registers the new package in its index. Factory 2 then detects the new package and automatically identifies all container images that depend on OpenSSL. It triggers automatic rebuilds for all affected images—potentially 19,200 or more images in a large deployment—tests each rebuilt image, and stages them for deployment.

Crucially, all images are updated in parallel rather than sequentially. This cascade enables the 12-24 hour patching timeline that would be impossible in traditional architectures where each image must be rebuilt independently.

This cascade enables the 12-24 hour patching that's impossible with decoupled systems.

Security Isolation

Each factory has its own security context:

Factory 1 Security Posture

Factory 1 (Package Factory):  Purpose: Verify and build packages  Privileges:    - Read-only access to upstream repositories    - Network access to package registries    - Build environment (compiler, build tools)    - Signing with Package Factory key   Cannot:    - Modify built packages (sign with wrong key)    - Access deployment credentials    - Deploy to production    - View application secrets

Factory 2 Security Posture

Factory 2 (Image Vault):  Purpose: Assemble images from verified packages  Privileges:    - Read-only access to Factory 1 packages    - Application source code access    - Signing with Image Vault key    - Deployment orchestration   Cannot:    - Rebuild packages (only consume verified ones)    - Access upstream repositories    - Sign with Package Factory key    - Modify packages

This separation of duties means compromising one factory doesn't compromise the other.

Use Case: Vulnerability in Transitive Dependency

Scenario: A vulnerability is found in lodash (used by express).

Traditional approach:  Developer updates express dependency  Developer commits change  Developer runs npm install (which pulls new lodash)  CI/CD builds and tests  Repeats for 400+ microservices  Timeline: 2-4 weeks CleanStart approach:  Factory 1 detects lodash vulnerability  Factory 1 rebuilds lodash with security patch  Factory 1 automatically rebuilds express (depends on lodash)  Factory 2 detects updated express  Factory 2 triggers automatic rebuilds of all 19,200 dependent images  All images test in parallel  Timeline: 2-4 hours

The two-factory architecture enables automated, parallelized patching at scale.

Use Case: Canary Deployment

Factories support safe rollout of new versions:

Factory 1 detects a critical security patch for OpenSSL 1.1.1y, signs it with the Package Factory key, marks it as "pre-release" for canary testing, and awaits approval from Image Vault. Factory 2 then detects the new package and builds canary images incorporating it. These canary images are deployed to 5% of production (approximately 1,000 images). The system monitors the canary deployment for 24 hours. If everything is stable, Factory 2 promotes the version to stable. If issues arise, Factory 2 rolls back to the previous version. Once confirmed stable, the remaining 95% of production (19,200 images) receives the update.

This risk-managed approach is impossible without a two-factory design.

Cost Benefits

The two-factory architecture delivers substantial benefits across operational, resource, and security dimensions. On the operational side, builds proceed in parallel rather than sequentially, drastically reducing time to remediate vulnerabilities. Packages become reusable across multiple images without requiring rebuilds, enabling significant cost savings at scale. Dependency updates are automatic, with the system detecting new package versions and automatically triggering image rebuilds, eliminating manual work. The overall burden of manual remediation effort is substantially reduced as the system handles cascading updates automatically.

Resource efficiency is improved through several mechanisms. Cache hits reduce rebuild time significantly, as packages built once can be reused across many images. Layer sharing ensures that common base images and dependency sets are not duplicated across the registry. Dependency graph optimization reduces the number of images that need rebuilding when an upstream dependency updates. And reduced image registry storage results from efficient deduplication and garbage collection.

Security efficiency is achieved through centralized vulnerability scanning, where vulnerabilities are identified once at the package level rather than repeatedly for each image. Automatic security updates ensure that vulnerabilities are patched at scale without manual intervention. Comprehensive audit trails document every step of the build process, supporting compliance requirements. And the zero-trust verification model ensures that every artifact—package, image, or configuration—is cryptographically verified before use, eliminating opportunities for tampering.

The Two-Factory Philosophy

The two-factory architecture embodies a principle: Do one thing well.

Factory 1 does packages: Verifies, builds, signs, indexes. Factory 2 does images: Assembles, tests, hardens, distributes.

Each factory optimizes for its specific domain. Together, they create a supply chain that's both secure and efficient.

This separation is the foundation of CleanStart's ability to deliver security at scale.