Purpose
This guide helps your organization's procurement, legal, and security teams evaluate CleanStart as a critical infrastructure vendor. Use this document during vendor risk assessments, RFX responses, and compliance reviews.
Company and Product Overview
What CleanStart Is
CleanStart is a container image vendor specializing in hardened, minimal images designed for security-sensitive production environments. We build and distribute container images, not SaaS services.
Delivery Model
CleanStart publishes container images to registry.cleanstart.com, an OCI-compatible registry, and supporting APK packages to clnpkgs.clnstrt.dev in the Alpine package ecosystem. The architecture requires no cloud dependency—images work offline after pull with no runtime phone-home and no agent. Images are portable and run on any OCI-compliant container runtime including Docker, containerd, Podman, and CRI-O.
Key Differentiators
CleanStart employs a comprehensive approach to container security by compiling every component from verified source code rather than repackaging upstream binaries. The company uses a two-factory architecture where Factory 1 (compiler bootstrap) is isolated from Factory 2 (package builds), ensuring security separation. Reproducible builds enable deterministic compilation allowing independent verification by customers. Minimal image footprint uses the APK package manager with subpackage stripping, typically reducing size 50-80% smaller than standard distros. All images are versioned, signed, and never modified after publication, maintaining immutable distribution.
Supply Chain Risk Assessment
Upstream Dependency Risk
Risk Statement: CleanStart's upstream dependencies could introduce vulnerabilities.
Mitigation Strategy:
CleanStart compiles all software from verified upstream source code rather than repackaging Alpine, Debian, Ubuntu, or other distro binary packages. Every compilation is auditable via SLSA Level 4 provenance. The company employs a two-factory architecture where Factory 1 (compiler bootstrap) produces a minimal compiler toolchain from source, and Factory 2 (package builds) uses Factory 1 output to build application packages. This isolation prevents supply chain contamination between layers.
All source URLs and checksums are verified before compilation. Git commit SHAs are referenced for security-critical components, and GPG signature verification is performed on upstream releases. Every image includes cryptographic proof of build origin and inputs via SLSA Level 4 provenance. Customers can independently verify the image hash through build step and source repository down to commit hash. This enables detection of tampering, unauthorized builds, or supply chain injection.
Your Assessment Checklist:
To properly evaluate this mitigation, you should obtain SLSA provenance for multiple images and verify the provenance chain using cosign. Cross-check the source repositories against CVE databases to ensure upstream components don't have known vulnerabilities. Confirm Factory 1/Factory 2 isolation in the build documentation to verify the supply chain architecture is truly segregated.
Single-Vendor Risk
Risk Statement: What happens if CleanStart ceases operations?
Mitigation Strategy:
Images are standard OCI artifacts that are portable to any container runtime and any registry. There are no proprietary formats or CleanStart-specific tooling required. Images run in Docker, Kubernetes, OpenShift, AWS ECS, Azure ACI, and other environments without modification.
Images can be stored in customer-owned registries including ECR, ACR, GCR, Harbor, Nexus, JFrog, and Quay. Customers can mirror the entire CleanStart image catalog to air-gapped internal registries. SBOMs enable reconstruction of equivalent images from source, providing build continuity.
Deterministic compilation means customers can independently rebuild images, with all required inputs documented including exact source commits, compiler version, and build flags. Customers can recreate identical images by following CleanStart's public build configuration. Every image includes Software Bill of Materials in SPDX 3.0 and CycloneDX 1.4 formats. These documents list every component, version, and source repository, enabling hand-off to alternative vendors or internal teams.
Recommended Approach:
# Mirror entire catalog to internal registryskopeo sync --src docker --dest docker \ registry.cleanstart.com/cleanstart \ myregistry.internal/cleanstart # Archives images for air-gapped environmentspodman save registry.cleanstart.com/cleanstart/python:3.12 | \ tar -czf cleanstart-python-3.12.tar.gzYour Assessment Checklist:
Begin by confirming that all images are standard OCI format with no proprietary extensions or lock-in mechanisms. Set up a registry mirror in your test environment to validate the mirroring capability. Download and archive SBOMs for all critical images you use and document the SBOM format. Document the build reproducibility process so your team understands exactly how to rebuild any image if needed. Review any source escrow options that may be available from CleanStart as additional insurance.
Continuity and Escrow
Source Code Escrow
CleanStart maintains repositories on public platforms including GitHub and GitLab with full build tooling. All source is available without escrow agreement, build scripts are included in repositories, and customers can independently verify builds. Documentation explains exactly how to rebuild any image.
Disaster Recovery Scenario:
If CleanStart operations cease, customers with mirrored images in internal registries continue operations uninterrupted. For new images, customers rebuild from SBOM and upstream sources using the documented process. For security patches, customers clone the CleanStart repository, apply patches, and rebuild using the documented toolchain.
Customer-Side Caching Strategies:
The primary strategy is registry mirrors, which are used by 99% of customers. This involves mirroring all images to an internal registry at image pull time across multiple tiers. Tier 1 is the corporate container registry (ECR, ACR, GCR), and Tier 2 is an air-gapped registry for isolated environments. Automated synchronization occurs daily or on-demand.
Local artifact storage archives critical images as tar.gz alongside SBOM, signatures, and attestations. This approach is useful for immutable compliance archives. Build independence maintains a clone of the CleanStart build repository to generate equivalent images on demand using the documented process. This requires source mirrors, a compiler toolchain, and build scripts.
Your Assessment Checklist:
Confirm that source code is publicly available without requiring any escrow agreements or special access. Obtain build reproducibility documentation that explains the full rebuild process. Design a registry mirror architecture that works for your operational model. Test air-gapped image deployment in your environment to ensure the process works as expected. Document your disaster recovery procedure so all relevant teams understand the continuity process.
Security Posture Assessment
Build Security
Standard Vendor Security Questionnaire Response
Question | CleanStart Answer | Evidence |
|---|---|---|
Do you perform SAST (Static Analysis)? | Yes — continuous on all source code | SAST report in compliance docs |
Do you perform DAST (Dynamic Analysis)? | Yes — functional testing on all images | 78-test inspection suite results |
Do you have vulnerability management? | Yes — with documented SLAs | SLA document (see below) |
Do you provide SBOMs? | Yes — SPDX 3.0 + CycloneDX 1.4 | Included with every image |
Do you sign artifacts? | Yes — Cosign/Sigstore signatures | cosign verify command works |
Do you support FIPS? | Yes — FIPS 140-3 validated modules | Separate FIPS image variants |
Is build auditable? | Yes — SLSA Level 4 + 11 artifacts | Verify with cosign verify-attestation |
Do you have SOC 2 Type II? | [See compliance section] | [Mapping document link] |
Do you have ISO 27001? | [See compliance section] | [Mapping document link] |
Incident response SLA? | Critical: 24hrs, High: 7d | SLA document below |
Dependency scanning? | Yes — on every build | Included in SBOM |
Supply chain security? | SLSA Level 4 provenance | Verify with cosign |
Encrypted artifact transmission? | Yes — TLS 1.3 on all registry access | Standard HTTPS |
Zero trust architecture? | Yes — all artifacts signed and verified | Cosign signatures required |
Do you scan for secrets? | Yes — git-secrets in build pipeline | Embedded in build logs |
Container image hardening? | Yes — shell-less, read-only, non-root | Security hardening section below |
Security Hardening Architecture
Every CleanStart image includes hardening controls:
Control | Implementation | Verification |
|---|---|---|
No shell | Busybox/dash removed from image |
|
No package manager | apk removed after package installation |
|
Non-root user | UID 65532, no sudo |
|
Read-only root FS | Root filesystem mounted read-only |
|
Minimal SUID/SGID | Only essential setuid binaries retained | Find SUID binaries: count < 5 |
Minimal attack surface | ~78% smaller than standard distros | Image size typically 50-150 MB |
FIPS 140-3 mode (FIPS images) | Cryptographic modules validated |
|
Cosign signatures | Every image cryptographically signed |
|
SBOM attestation | Provenance attestation signed |
|
SLSA provenance | Build provenance securely recorded |
|
Data Handling
CleanStart does NOT process, collect, or store customer data. Images do not phone home, report usage, or send metrics. There is no runtime daemon, sidecar, or monitoring component. CleanSight is optional and customer-deployed, running entirely in the customer environment with data staying with the customer and customer-controlled configuration.
Compliance Implications:
For GDPR compliance, no personal data is processed, so no Data Processing Agreement is required. Under CCPA, no data is collected, so no privacy notice is required. For HIPAA-regulated healthcare environments, the images are suitable because there is no data access by the vendor. Under PCI-DSS, the images are suitable for cardholder environments since there is no data access by the vendor.
Incident Response and Vulnerability Management
CVE Detection and Response Process
The company continuously scans upstream vulnerabilities from NVD, GHSA, and OSV to identify newly discovered vulnerabilities affecting CleanStart images. Impact is evaluated for each CleanStart image, customers are alerted per SLA timelines, vulnerable components are patched, patched images are published with updated SBOM and signature, and patches are verified through re-scanning.
Response SLAs:
Severity | Detection to Fix | Customer Notification |
|---|---|---|
Critical (CVSS ≥ 9.0) | 24 hours | Immediate |
High (CVSS 7.0-8.9) | 7 days | Within 24 hours |
Medium (CVSS 4.0-6.9) | 30 days | Weekly digest |
Low (CVSS < 4.0) | 90 days | Monthly digest |
Notification Channels:
CleanStart sends email security advisories through an opt-in system, provides an RSS/Atom feed that is publicly accessible, offers webhook notifications that can be configured, and includes the CleanSight dashboard which is optional and customer-deployed.
Escalation Path:
For P1 issues involving critical CVEs or production incidents, the response target is 1 hour. For P2 issues involving high CVEs or operational problems, the response target is 4 hours. For P3 issues involving medium CVEs or questions, the response target is 1 day. For P4 issues involving low CVEs or feature requests, the approach is best effort support.
Compliance Certifications
Framework Mapping and Status
Framework | Status | Evidence | Relevance |
|---|---|---|---|
FIPS 140-3 | Validated | Separate image variants with validated crypto modules | Required for: government, defense, finance |
SLSA Level 4 | Compliant | Provenance attestations on every image | Required for: supply chain audit, zero trust |
CIS Docker Benchmark | 94/94 controls | Configuration report | Required for: infrastructure hardening, compliance audit |
DISA STIG | Compliant | Assessment mapping document | Required for: DoD contracts, government agencies |
SOC 2 Type II | [Status] | [Link to detailed mapping] | Required for: enterprise customers, SaaS integrations |
ISO 27001 | [Status] | [Link to detailed mapping] | Required for: regulated industries, European orgs |
PCI-DSS v4.0 | Compliant | Mapping to 12 major requirements | Required for: payment processing, fintech, e-commerce |
HIPAA | Compliant | Suitable for healthcare (no data access, encryption supported) | Required for: healthcare, health insurance, medical devices |
FedRAMP High | [Assessment status] | [Link to documentation] | Required for: federal government, GSA schedule |
NIST Cybersecurity Framework | Aligned | Mapping to 5 functions (Identify, Protect, Detect, Respond, Recover) | Recommended for: any organization (not mandatory) |
OpenSSF Scorecard | [Score] | Public GitHub repository score | Recommended for: evaluating software supply chain |
Certification Acquisition Process
For certifications not yet completed, you should review the public roadmap to see planned certifications, contact support for estimated completion dates, and work with the CleanStart team on requirements and remediation gap analysis.
Operational Risk Assessment
Image Update Frequency and Predictability
Planned Release Schedule:
Security patches are published outside the regular schedule as needed within the SLA window. Monthly base releases occur on the second Tuesday of each month unless a critical security issue accelerates the schedule. Emergency hotfixes are released within 24 hours for Critical CVEs and within 7 days for High CVEs. Major versions receive 6 months advance notice before sunset.
Versioning Scheme:
registry.cleanstart.com/cleanstart/python:MAJOR.MINOR-buildDATEExample:
python:3.12-build20250315 # Specific build datepython:3.12 # Latest patch versionpython:3.12.5-build20250315 # Specific patch levelVersion Support Timeline:
The current major version receives full support including security patches and bug fixes. The previous major version receives security patches only for 12 months. Older versions receive best effort support with no guaranteed SLA.
For example, if Python 4.0 releases, then Python 4.0.x receives full support, Python 3.12.x receives security patches and bugfixes, Python 3.11.x receives security patches only, and Python 3.10 and earlier reaches end of life with no support.
Breaking Changes Policy
What constitutes a breaking change:
Breaking changes include base OS changes (Alpine 3.19 → 3.20), major version bumps in primary components (Python 3.11 → 3.12), removal of commonly-used packages or binaries, and changes in default behavior or configuration.
Communication process:
A deprecation notice occurs 6 months in advance with warning. Documentation includes a migration guide provided concurrently. Test images are available 4 weeks before production release. Email notification is sent to all active customers. Support escalation receives priority support during the transition period.
Procurement Checklist
Use this checklist as your organization's approval workflow:
Pre-Procurement (Week 1-2)
Security Review
Your CISO or Security Officer should review this vendor assessment document thoroughly. Your security team should validate the hardening controls including shell-less images, non-root execution, and read-only filesystems. A threat model assessment should be completed specifically for the container image supply chain to understand your organization's specific risks.
Legal Review
Your legal team should review the Master Service Agreement (MSA) for all terms and conditions. Ensure that liability and indemnification clauses are acceptable to your organization. If GDPR or CCPA compliance is required, a Data Processing Agreement should be reviewed and signed. IP rights and open source terms should be thoroughly reviewed to ensure compatibility with your organization's policies.
Compliance Review
Your compliance officer should confirm that all certifications presented by CleanStart (FIPS, SOC 2, ISO 27001, etc.) are acceptable for your regulatory environment. Identify all regulatory requirements applicable to your organization (PCI-DSS, HIPAA, FedRAMP, etc.). Document the audit trail requirements needed to satisfy your regulators.
Technical Setup (Week 2-3)
Registry Access
Provision an API key from your CleanStart account for programmatic access. Add registry credentials to your container runtime, including the Docker daemon, containerd configuration, and Kubernetes ImagePullSecrets. Verify that your network can resolve registry.cleanstart.com and clnpkgs.clnstrt.dev. Configure a registry mirror as your primary strategy: mirror all images to your internal registry at pull time. Create a destination registry using ECR, ACR, GCR, Harbor, Nexus, or Quay. Set up mirror automation to sync daily or on-demand. Document your archive procedure for air-gapped environments.
Build Infrastructure
Configure your CI/CD pipeline to pull images from registry.cleanstart.com. Integrate image signing verification into your deployment pipeline. Integrate SBOM and attestation downloads for your audit trail. Set your pull policy to "Always" or use digest-based pinning to ensure reproducibility.
Artifact Management
Add the CleanStart Cosign public key to your artifact verification system. Establish a procedure for SBOM storage either in a central archive or alongside each deployment. Automate attestation verification in your deployment pipeline so all images are verified before being deployed.
Acceptance Testing (Week 3-4)
Image Integrity
Download the Cosign public key from the CleanStart public repository. Verify the signature on at least 3 sample images by running cosign verify registry.cleanstart.com/cleanstart/.... Verify the SBOM attestation using cosign verify-attestation --type spdxjson registry.cleanstart.com/cleanstart/.... Verify SLSA provenance using cosign verify-attestation --type slsaprovenance registry.cleanstart.com/cleanstart/.... Run an independent vulnerability scan using tools like Trivy or Grype and confirm that the results match the CleanStart SBOM.
Security Hardening
Test that the image has no shell by attempting docker run --entrypoint /bin/sh registry.cleanstart.com/cleanstart/... -c "echo fail" and verify it returns an error. Verify that the image runs as non-root by running docker run registry.cleanstart.com/cleanstart/... id and confirming it shows uid=65532. Test that the filesystem is read-only by attempting docker run registry.cleanstart.com/cleanstart/... touch /test-file and verifying it fails. Confirm that the package manager is not available by testing docker run registry.cleanstart.com/cleanstart/... apk add curl and confirming it returns command not found. Run a CIS Docker Benchmark scan and verify that all 94 controls pass. If using a FIPS image, verify FIPS validation by running openssl fips show and confirming it returns 1.
Application Compatibility
Deploy your test application in your dev environment using a CleanStart image. Verify that application startup is successful and health checks pass. Confirm database connectivity is working. Test that external API calls succeeded, including TLS verification and DNS resolution. Establish a performance baseline for startup time, memory usage, CPU consumption, and request latency. Verify that secrets injection is working with your secrets management system (Kubernetes Secrets, Vault, environment variables). Test that volume mounts work correctly. Confirm that logging and stdout are captured successfully.
Support and SLA (Week 4)
Support Tier Selected
Determine which support tier matches your needs from Community (Free with best effort support), Professional (email support with named contact), or Enterprise (24/7 support with custom builds and dedicated engineer). Sign the support agreement with CleanStart.
SLA Agreement
Review the CVE response SLAs and confirm they are acceptable (Critical: 24h, High: 7d, Medium: 30d, Low: 90d). Confirm that the image availability SLA is acceptable (typically 99.9% uptime on registry.cleanstart.com). Verify that support response times are acceptable for your needs (Community: best effort, Professional: 1 day, Enterprise: 4 hours). Register your escalation contacts with CleanStart.
Advisory Notification
Subscribe to the security advisory email list for critical updates. Configure the RSS/Atom feed in your monitoring system. Enable webhook notifications if you have an Enterprise tier subscription. Verify that your incident contact email is registered and monitored.
Production Promotion (Week 4-5)
Architecture Design
Decide on your image pinning strategy, with digest-based pinning being recommended for the highest level of reproducibility. Document your registry mirror strategy. Document your air-gapped deployment procedure. Test your disaster recovery process to verify that you can pull from your mirror if registry.cleanstart.com becomes unavailable.
Final Approvals
Obtain sign-off from your security team. Obtain sign-off from your compliance officer. Obtain sign-off from your CTO or technology director. Obtain procurement approval from your procurement team. Include date signatures from all parties.
Production Readiness
Verify that your production cluster can pull from your internal registry mirror. Ensure deployment is automated for production promotion. Document and test your rollback procedure. Configure monitoring and alerting for your containers. Create incident response playbooks that reference CleanStart support contacts.
Risk Mitigation Recommendations
Tier 1: Essential (Before Production)
Always mirror images to your own registry
The primary strategy uses the corporate container registry (ECR, ACR, GCR, Harbor). Deploy a secondary strategy with an air-gapped registry for isolated environments. Set up automated sync to occur daily or on-demand. This benefits your organization by ensuring you can survive registry.cleanstart.com outages and enabling offline deployments when needed.
Pin image digests, not tags
# WRONG (tag can change)FROM registry.cleanstart.com/cleanstart/python:3.12 # CORRECT (digest is immutable)FROM registry.cleanstart.com/cleanstart/python@sha256:abc123def456...This prevents surprise changes and enables audit trails for all your deployments.
Verify signatures on every pull
Configure your container runtime to require valid Cosign signatures. Use image admission policies such as Kubernetes ImagePolicy, Kyverno, and Sigstore Cosign. This prevents supply chain injection attacks from compromised registries or network man-in-the-middle attacks.
Download and archive SBOMs for audit trail
cosign download sbom registry.cleanstart.com/cleanstart/python:3.12 > sbom.spdx.jsonStore SBOMs alongside your production deployment manifests. This enables regulatory audit, compliance evidence, and supply chain transparency to all stakeholders.
Tier 2: Recommended (For Regulated Environments)
Subscribe to security advisories
Email notifications alert you for Critical and High CVEs within your SLA window. Webhook integration enables automated alert routing to your security tools. This detects vulnerabilities within your SLA window (24 hours Critical, 7 days High).
Implement policy enforcement
Configure admission controllers to reject unsigned images. Use scanning gates to block images with CVEs above your defined threshold. This prevents accidental deployment of vulnerable or untrusted images into your environment.
Maintain SBOM archive with deployment records
For each deployment, archive a directory containing manifest.yaml, sbom.spdx.json, sbom.cyclonedx.xml, attestation.slsaprovenance.json, and signature.json. This practice provides regulatory compliance evidence, enables incident response forensics, and maintains a complete supply chain audit trail for future investigations.
Document build reproducibility
Store the exact image digest used in production. Document upstream component versions from the SBOM. Maintain a clone of the CleanStart build repository. This enables independent image rebuilds and ensures you can achieve disaster recovery even if CleanStart is no longer available.
Tier 3: Advanced (For Critical Systems)
Test air-gapped deployment procedure
Export images as tar.gz for manual deployment in isolated environments. Test deployment in your isolated networks to verify the process works end-to-end. This ensures continuity if the registry becomes unavailable due to network outages or other issues.
Establish build independence capability
Maintain a clone of the CleanStart build repository in your environment. Verify that deterministic build reproducibility works using your own toolchain. Document all toolchain requirements so your team can rebuild any image. This provides ultimate insurance against vendor dependency and ensures long-term availability.
Integrate CleanSight (optional monitoring)
Deploy the CleanSight agent in production if available for your organization. Monitor for outdated images running in your production environment. This enables early detection of unpatched images and automatic recommendations for updates.
What to Read Next
For Security/Compliance Teams
acceptance-testing-guide.md: Consumer-side validation for QA teams. 78-test-inspection-suite.md: Internal CleanStart testing for confidence in builds. compliance-framework-mapping.md: Detailed mapping to FIPS, SOC 2, ISO 27001, etc.
For Procurement/Legal
sla-support-tiers.md: Service level agreements and support tier definitions. master-service-agreement.md: Contractual terms and conditions.
For Operations/DevOps
image-registry-setup.md: Configure registry mirror and CI/CD integration. policy-enforcement.md: Kubernetes ImagePolicy, Kyverno, Cosign admission control. disaster-recovery.md: Air-gapped deployment, build independence.
For Development Teams
getting-started.md: Pull images, build Dockerfile, deploy to Kubernetes. troubleshooting.md: Common issues and solutions.
Document Version: 1.0 Last Updated: 2025-03-22 Next Review: 2025-09-22 (or immediately upon major product change) Owner: CleanStart Product Team