Every build in CleanStart Source Intelligence Core produces 11 distinct artifacts. Each serves a specific purpose in the verification and governance pipeline. Together, they form an immutable record of what was built, how it was built, and what it contains.
1. SPDX 3.0 Software Bill of Materials
Purpose: Standardized inventory of all components, with detailed relationships and metadata.
Format: JSON-LD (JavaScript Object Notation for Linked Data)
Contents: The SPDX document lists every dependency with its exact version, includes license information for each package, documents relationships between components, records cryptographic hashes of each element, and tracks vulnerability linkages for supply chain security.
Why it matters: SPDX is the industry standard. Insurance companies, compliance auditors, and government agencies expect SPDX documents. It enables automated analysis across your entire software portfolio.
{ "spdxVersion": "SPDX-3.0.0", "creationInfo": { "created": "2024-03-20T14:30:00Z", "creators": ["Tool: cleanstart-factory-v2"] }, "packages": [ { "SPDXID": "SPDXRef-Package-express", "name": "express", "versionInfo": "4.18.2", "downloadLocation": "https://registry.npmjs.org/express/-/express-4.18.2.tgz", "filesAnalyzed": true, "checksums": [ { "algorithm": "SHA256", "checksumValue": "abc123..." } ] } ]}Use cases: SPDX documents serve multiple critical purposes including providing a board-level inventory of all software components, enabling license compliance reporting to verify legal obligations, supporting insurance policy verification for coverage determination, and creating regulatory audit evidence required by compliance frameworks.
2. CycloneDX 1.4 Bill of Materials
Purpose: Lightweight, developer-friendly BOM format focused on software composition and vulnerabilities.
Format: XML and JSON variants
Key differences from SPDX: More compact representation. Built-in vulnerability tracking Service metadata support Licensing simplified to commons patterns
Example:
<?xml version="1.0"?><bom xmlns="http://cyclonedx.org/schema/bom/1.4"> <metadata> <timestamp>2024-03-20T14:30:00Z</timestamp> <tools> <tool> <vendor>cleanstart</vendor> <name>factory-builder</name> <version>2.0.0</version> </tool> </tools> </metadata> <components> <component type="library" bom-ref="pkg:npm/express@4.18.2"> <name>express</name> <version>4.18.2</version> <purl>pkg:npm/express@4.18.2</purl> <vulnerabilities> <vulnerability ref="cve-2024-0001"> <id>CVE-2024-0001</id> <source name="NVD">...</source> </vulnerability> </vulnerabilities> </component> </components></bom>Use cases: Development team daily usage. Vulnerability scanning integration Dependency update tracking Package manager integration
3. SLSA L4 Build Attestation
Purpose: Cryptographic proof that the build process was secure and followed approved procedures.
Format: SLSA Provenance v1.0 (JSON)
What it verifies:
Who initiated the build (identity verified) When the build occurred (timestamp) What source code was built (git commit hash) How the build was done (build parameters) What environment it was built in (build runner specs) The build output hashes (artifact integrity)
Full example:
{ "_type": "https://slsa.dev/schema/v1.0/provenance", "predicate": { "builder": { "id": "https://github.com/cleanstart/factory/builders/v2.0" }, "buildType": "https://cleanstart.dev/buildType/standard", "invocation": { "configSource": { "uri": "git+https://github.com/myapp/repo.git", "digest": { "sha256": "abc123def456..." }, "entryPoint": "Dockerfile" }, "parameters": { "buildTarget": "production", "optimizationLevel": "O2", "reproducible": true }, "environment": { "runner": "google-cloud-build-n2-standard-4", "containerImage": "gcr.io/cleanstart-builders/builder:v2.0" } }, "buildConfig": { "sourceChain": [ { "revision": "abc123def456...", "fromRevision": "def456ghi789..." } ], "resolvedDependencies": [ { "uri": "npm:express@4.18.2", "digest": { "sha256": "..." } } ] }, "materials": { "dockerfile": { "uri": "file:///build/Dockerfile", "digest": {"sha256": "..."} } }, "byproducts": { "stderr": "Build completed successfully\nTimestamp: ...", "buildLog": "file:///artifacts/build.log" }, "completeness": { "parameters": true, "environment": true, "materials": true } }}Signature: Signed by CleanStart's build service account using a key stored in Cloud KMS.
Use cases: Governance verification ("was this built securely?"). Audit trails for compliance Supply chain integrity verification Detection of build environment tampering
4. In-Toto Link Metadata
Purpose: Detailed tracking of each step in the build pipeline with cryptographic linkage between steps.
Format: JSON (In-Toto v1.0 specification)
Steps tracked: Source code checkout. Dependency resolution Build compilation Tests execution Artifact generation Signing and attestation
Example link for "compile" step:
{ "_type": "link", "name": "compile", "materials": { "src/app.js": { "sha256": "abc123..." }, "Dockerfile": { "sha256": "def456..." } }, "products": { "app.o": { "sha256": "ghi789..." } }, "byproducts": { "return-value": 0, "stdout": "Compilation successful", "stderr": "" }, "environment": { "USER": "builduser", "PWD": "/build" }, "command": [ "gcc", "-c", "src/app.c", "-o", "app.o" ]}The full chain creates an immutable timeline of the build process.
Use cases: Detailed audit of what happened during the build. Detecting when and where tampering occurred Understanding dependency graph evolution Reproducibility verification
5. Cosign Signature
Purpose: Cryptographic signature proving the artifacts haven't been modified since the build.
Format: OCI image signature (stored in OCI artifact manifest)
How it works:
# During buildcosign sign \ --key $SIGNING_KEY \ --tlog-upload=true \ gcr.io/cleanstart/myapp:1.0.0 # On verificationcosign verify \ --key $PUBLIC_KEY \ gcr.io/cleanstart/myapp:1.0.0What's signed: OCI image digest (all layers). Timestamp of signature Signing identity Optional annotations (build reason, approval, etc.)
Signature log: Stored in transparency log for long-term verification even if your key is lost.
Use cases: Ensuring artifact hasn't been modified in transit. Supply chain verification (verifying who built it) Image pull policies (only run signed images) Revocation of compromised builds
6. Vulnerability Exposure Exchange (VEX) Document
Purpose: Formal assertions about which vulnerabilities affect your application.
Format: NTIA-compliant JSON (or SBOM extension)
Typical content:
{ "vex_format": "cyclonedx", "vex_version": "1.0", "vulnerabilities": [ { "cve": "CVE-2024-1234", "component": "openssl", "status": "not_affected", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "The TLS 1.3 session ticket handling is only triggered if client requests session resumption. Our implementation always creates new sessions." }, { "cve": "CVE-2024-5678", "component": "curl", "status": "affected", "remediation": { "recommendation": "Update curl from 7.88 to 7.91", "date": "2024-03-25" } } ]}Why this matters: Automates the distinction between "vulnerable code present" and "vulnerability affects us".
Use cases: Risk prioritization. Automated security dashboards Compliance reporting Insurance policy verification
7. Build Provenance Record
Purpose: Human-readable summary of build origin and parameters.
Format: Structured metadata (JSON with signatures)
Contains: Source repository and commit. Build timestamp and duration Builder identity and version Build parameters (optimization flags, target platform, etc.) Output artifacts and their hashes Approval chain (who approved this build)
build_id: build-20240320-143051-abc123source: repository: https://github.com/myapp/repo commit: abc123def456... branch: main tag: v1.0.0 verified_commit_signature: truebuild_environment: builder_version: cleanstart-v2.0.0 platform: linux/amd64 build_runner: google-cloud-build timestamp: 2024-03-20T14:30:51Z duration_seconds: 287parameters: optimization_level: O2 reproducible: true security_checks: allartifacts: - name: app.tar.gz sha256: abc123... size_bytes: 52428800 - name: app.tar.gz.sig signature_algorithm: RSASSA-PKCS1-v1_5approval_chain: - approver: security-team timestamp: 2024-03-20T14:25:00Z - approver: ops-team timestamp: 2024-03-20T14:28:00ZUse cases: Governance and policy enforcement. Change tracking Incident investigation Compliance audit evidence
8. Build Log (Structured)
Purpose: Complete transcript of the build process with structured machine-readable format.
Format: Newline-delimited JSON (NDJSON) with timestamps and severity levels
Example entries:
{"timestamp": "2024-03-20T14:30:00Z", "level": "info", "component": "builder", "message": "Build started", "build_id": "abc123"}{"timestamp": "2024-03-20T14:30:05Z", "level": "info", "component": "source", "message": "Source code fetched", "size_bytes": 5242880, "hash": "def456"}{"timestamp": "2024-03-20T14:30:12Z", "level": "info", "component": "resolver", "message": "Resolved 52 dependencies", "count": 52}{"timestamp": "2024-03-20T14:31:45Z", "level": "warning", "component": "vulnerability_scan", "message": "847 CVEs found in dependency tree", "after_filtering": 40}{"timestamp": "2024-03-20T14:33:51Z", "level": "info", "component": "image", "message": "Image built successfully", "digest": "sha256:ghi789", "size_bytes": 52428800}Searchable fields: timestamp, severity, component, message, metrics
Use cases: Post-incident analysis. Performance optimization Debugging build failures Security event investigation
9. Test Results Summary
Purpose: Proof that automated tests passed before the artifact was released.
Format: JSON with detailed test execution metadata
Contents:
{ "test_run_id": "test-20240320-143051", "timestamp": "2024-03-20T14:33:00Z", "total_tests": 847, "passed": 847, "failed": 0, "skipped": 0, "coverage": { "line_coverage": 94.2, "branch_coverage": 87.5, "function_coverage": 96.1 }, "test_suites": [ { "name": "unit_tests", "passed": 523, "failed": 0, "duration_ms": 4521 }, { "name": "integration_tests", "passed": 267, "failed": 0, "duration_ms": 18932 }, { "name": "security_tests", "passed": 57, "failed": 0, "duration_ms": 2145 } ], "security_checks": { "sast_issues": 0, "dast_issues": 0, "dependency_vulnerabilities": 40 }}Policy gates: No artifact is released if tests don't meet threshold (e.g., 85% coverage minimum).
Use cases: Quality assurance verification. Regression detection Coverage tracking Policy enforcement
10. Helm Chart (for Kubernetes)
Purpose: Declarative configuration for deploying the built application to Kubernetes.
Format: Helm 3 chart structure
Key files: A Helm chart contains several essential components. The Chart.yaml file holds chart metadata. The values.yaml file provides default configuration. The templates/ directory contains deployment templates including deployment.yaml (the Pod deployment spec), service.yaml (the Service definition), and configmap.yaml (application configuration). The values-prod.yaml file provides production overrides for environment-specific settings.
Immutability: The chart is versioned alongside the application version and signed.
# Chart.yamlapiVersion: v2name: myappversion: 1.0.0appVersion: 1.0.0maintainers: - name: Platform Team email: platform@example.comWhy it matters: Deployment is reproducible and version-controlled. Configuration changes are auditable Rollbacks are instant (revert to previous chart version) GitOps workflows integrate automatically
Use cases: Kubernetes cluster deployments. Multi-environment promotion Configuration management Disaster recovery and rollback
11. OCI Image
Purpose: The final, production-ready container image.
Format: OCI Image Format Specification (Docker-compatible)
Structure: An OCI Image consists of several components. The Image Index contains manifests for multiple architectures (supporting multi-platform builds). The Image Manifest holds references to all layers. The Config Blob stores image metadata. The Layer Blobs include the base OS layer (Alpine, Debian, etc.), the runtime layer (Java, Node.js, Python, etc.), a dependencies layer, and the application layer.
Metadata included: All previous artifacts embedded (SBOM, attestations, VEX). Cryptographic signatures Build provenance Digest (SHA256 of entire image)
Reproducibility: If rebuilding produces a different digest, something changed. The build is not reproducible.
Use cases: Container orchestration platforms. Serverless deployment Disaster recovery Distribution and replication
The 11-Artifact Workflow
The build workflow starts with application source code, which flows through the build pipeline. The pipeline generates 11 artifacts: SPDX 3.0 SBOM, CycloneDX SBOM, SLSA L4 Attestation, In-Toto Metadata, Cosign Signature, VEX Document, Build Provenance, Structured Build Log, Test Results, Helm Chart, and OCI Image. All artifacts are signed and distributed together, enabling deployment with full chain-of-custody verification.
Verification Chain
Each artifact depends on and references the others:
SBOM references the resolved dependencies (integrity-checked) SLSA Attestation references the source commit and build parameters Cosign Signature covers the OCI image and attestation In-Toto links connect each build step VEX document updates the SBOM with vulnerability status Test Results are referenced in the build log Helm Chart references the image digest
If any artifact is tampered with, the cryptographic chain breaks and verification fails.
Why This Matters
Organizations need all 11 artifacts because:
- Compliance: Auditors require specific standards (SPDX, SLSA)
- Security: Multiple verification vectors catch different attack types
- Operations: Teams need both technical records (logs, attestations) and business records (test results, approvals)
- Governance: Policies are enforced through structured metadata
- Supply chain: Downstreams need proof of what they're receiving
The artifacts transform a "container image" from a black box into a fully-transparent, cryptographically-secured software component with complete chain-of-custody.