CI/CD Pipeline Architecture for Signed Container Images

Related Fundamentals: For background on how CI/CD integrates with container images, see Container Images in CI/CD and Prebuild Stage Security. For deeper security architecture, see Build Stage Security.

The CleanStart CI/CD architecture provides a 5-stage secure pipeline that takes source code through automated security analysis, hermetic builds, environment-specific promotion, and cryptographic verification before pushing to registries. This architecture is platform-agnostic—the same principles apply to GitHub Actions, GitLab CI, Google Cloud Build, Jenkins, and Azure DevOps.

Why This Matters

Traditional CI/CD pipelines have three critical weaknesses:

1. Supply chain attacks: Compromised dependencies or build steps can inject malicious code
2. Configuration drift: Hand-tuned build parameters differ from documented standards
3. Audit gaps: Unsigned artifacts and missing provenance make compliance impossible

CleanStart's pipeline design eliminates these risks through hermetic builds (reproducible, isolated), attestation (cryptographic proof of what happened), and verification gates (blocks non-compliant artifacts).

5-Stage Secure Pipeline

Stage 1: Source Analysis (Security-First)

What happens: Static code analysis (SAST) scans source for vulnerabilities. Dependency scanning identifies known CVEs in your dependencies. SBOM generation creates a complete bill of materials. Intelligence queries run against CleanStart Source Intelligence Core.

Tools used: Your existing SAST tools (SonarQube, Snyk, Checkmarx, etc.). clnstrt-cli analyze-dependencies for supply chain risk. clnstrt-cli generate-sbom for SPDX/CycloneDX output.

Why it's first: Fail fast — catch issues before building. Leverage existing tools your team knows. Generate artifacts needed for later stages.

Example flow:

When a commit is pushed, Stage 1 begins by performing a SAST scan on the source code. Next, dependency analysis is run to identify all project dependencies. Following that, a Software Bill of Materials (SBOM) is generated. If no critical issues are found during these scans, the pipeline proceeds to Stage 2.

Stage 2: Hermetic Build (Isolated & Reproducible)

What happens: Build executes in isolated sandbox (no internet, locked to dependencies). All inputs are explicit and versioned. Output is deterministic — same input always produces same binary. Build artifacts include dependency SBOMs and provenance. No secrets, no external state, no side effects.

Hermetic means: No external network calls during build (all dependencies pre-fetched). No host tools used (alpine base, minimal toolchain). No dynamic dependencies (pin all versions). Reproducible from git commit SHA alone.

CleanStart images used: -builder variant for compile/test phase. -prod variant for runtime (10x smaller, production-ready). -dev variant for testing/debugging.

Example Docker pattern:

FROM cleanstart-gcc:14-builder AS builderCOPY . /srcWORKDIR /srcRUN ./build.shRUN clnstrt-cli generate-sbom --output /sbom.spdx FROM cleanstart-gcc:14-prodCOPY --from=builder /app /appCOPY --from=builder /sbom.spdx /attestations/sbom.spdx

Stage 3: Dev/Prod Fork (Environment-Specific Promotion)

What happens: Dev branch: Images pushed to dev registry, used for staging/integration tests. Prod branch: Images pushed to prod registry, undergo additional verification. Manual approval gate between environments (optional but recommended). Environment-specific configuration baked into deployment.

Dev Registry: Faster feedback, less strict verification. Used for integration testing, canary deployments. Ephemeral images (can be garbage-collected). No SLA requirements.

Prod Registry: Strict scanning, signed attestations, approved configuration. Used for production deployments. Kept for compliance retention (1-7 years). Full supply chain provenance.

Example GitHub Actions branching:

on:  push:    branches: [main, develop] jobs:  build:    steps:      - name: Determine target registry        run: |          if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then            echo "REGISTRY=gcr.io/prod-project" >> $GITHUB_ENV            echo "STRICT_VERIFICATION=true" >> $GITHUB_ENV          else            echo "REGISTRY=gcr.io/dev-project" >> $GITHUB_ENV            echo "STRICT_VERIFICATION=false" >> $GITHUB_ENV          fi

Stage 4: Verification (Security Gate)

What happens: FIPS compliance check (algorithms, modes). STIG baseline verification (container hardening). Artifact signing with KMS/Cosign keys. Attestation generation (SLSA, in-toto format). Vulnerability scanning (images, dependencies). VEX document generation (false positive triage).

Verification checks:

1. Image scan results (zero critical, <5 high by default)
2. SBOM validation (all dependencies identified)
3. Provenance chain (unbroken from source to binary)
4. Signature validity (chain of trust intact)
5. Configuration compliance (matches security policy)

Example verification gate:

# Verify image before pushclnstrt-cli verify \  --image my-app:latest \  --require-signature \  --policy-file security-policy.yaml \  --max-vulnerabilities 5 \  --require-sbom \  --fail-on-fips-issues

Stage 5: OCI Push & Registry Integration

What happens: Signed image pushed to registry. Attestations (SLSA, SBOM, vulnerability scan) attached. Registry performs additional scanning (Google Artifact Registry, Harbor, etc.). Image URI and digest recorded for audit trail. Deployment systems consume verified image.

What gets pushed: OCI image (layered, FIPS-compliant). Image signature (Cosign format). SLSA provenance attestation. SBOM attestation (SPDX/CycloneDX). Vulnerability report. Custom attestations (your own policy checks).

Registry verification:

# Later, during deploymentcosign verify --certificate-identity=build-sa@project.iam.gserviceaccount.com \  gcr.io/my-project/app:v1.2.3 cosign verify-attestation --type slsa --certificate-identity=... \  gcr.io/my-project/app:v1.2.3

Key Design Principles

1. Fail Fast, Secure Always

Security checks run in parallel where possible. Failures immediately stop the pipeline. No "ignore and continue" — every security gate is blocking.

2. Cryptographic Proof, Not Trust

Every artifact is signed with non-repudiable keys. Supply chain proven through attestation chain. Verification is deterministic (not policy-based guessing).

3. Audit Trail First

Every action recorded: who, what, when, how, why. Compliance logs generated automatically. Forensics possible even months/years later.

4. Developer Friction ≈ Zero

Single CLI command: clnstrt-cli sign --image my-app:v1. Platform-agnostic (GitHub, GitLab, GCP, Jenkins all work same way). Integrates into existing CI/CD with minimal changes.

Pipeline Customization Points

Scanning Tools

Replace/extend SAST, dependency, or container scanning tools without changing the overall flow.

Approval Gates

Add manual approval between stages (for PCI-DSS, SOC2) or keep fully automated.

Signing Keys

Cloud KMS (Google Cloud). AWS KMS. Vault. Cosign self-managed keys.

Registry Destinations

Google Artifact Registry. Harbor. DockerHub. Quay.io. Private registry (any OCI-compliant).

Custom Attestations

Add your own policy checks, business logic verification, or domain-specific validation.

Security Benefits

Common Pipeline Timeline

Stage 1 (Analysis): 2-5 minutes. Stage 2 (Build): 5-15 minutes (depends on codebase). Stage 3 (Promote): 1 minute. Stage 4 (Verify): 3-8 minutes. Stage 5 (Push): 1-2 minutes.

Total: 12-31 minutes for a complete secure pipeline run.

What's Next?

GitHub Actions Users: See github-actions.md for complete pipeline configuration. GitLab Users: See gitlab-ci.md for environment promotions and OIDC signing. Google Cloud Users: See google-cloud-build.md for KMS integration and Binary Authorization. Enterprise Users: See jenkins-azure-devops.md for headless CLI and agent configuration.