Skip to main content

​
Overview

CaseBender’s supply chain security ensures that every artifact you deploy has been built from verified source code, scanned for vulnerabilities, signed cryptographically, and attested with provenance. These controls run automatically in our CI/CD pipeline — not as optional steps, but as mandatory gates that block releases.

​
Live Pipeline Status

PipelineStatusRuns On
Security ScanSecurity ScanEvery PR and push to main
Supply Chain VerifySupply ChainEvery PR and push to main
Image SigningImage SigningEvery push to main/production
SLSA ProvenanceSLSA ProvenanceEvery push to main/production

​
Dependency Management

​
Version Pinning

All dependencies are pinned to exact versions to prevent supply chain attacks via version drift:
  • save-exact=true in .npmrc ensures every pnpm add pins to the exact version
  • strict-peer-dependencies=true catches incompatible peer dependency versions
  • pnpm install --frozen-lockfile in all Dockerfiles ensures builds use exactly the versions in the lockfile
  • Node.js version pinned via .nvmrc and .node-version (Node.js 20.x)
  • pnpm version pinned in Dockerfiles to prevent tool-level supply chain attacks

​
Automated Dependency Updates

Dependabot monitors for updates across three ecosystems:
EcosystemScheduleScope
npmWeekly (Monday)Production deps, dev deps, OpenTelemetry, Prisma (grouped)
DockerWeekly (Tuesday)Base images for all 7 services
GitHub ActionsWeekly (Wednesday)All CI/CD workflow action versions
Dependabot PRs are:
  • Automatically labeled with dependencies and security
  • Blocked from merging if they introduce HIGH or CRITICAL vulnerabilities
  • Reviewed by the security team before merge

​
Dependency Review

Every pull request is automatically checked for:
  • New dependencies with known vulnerabilities (HIGH/CRITICAL blocked)
  • Dependencies with forbidden licenses (copyleft licenses blocked)
  • Dependencies with no license (flagged for review)
  • Pre-release dependencies (documented and tracked)

​
Approved Component Registry

CaseBender maintains a documented registry of approved third-party components organized by risk tier:
TierRisk LevelExamplesReview Frequency
Tier 1Criticalnext-auth, prisma, bcrypt, joseEvery update reviewed
Tier 2HightRPC, zod, bullmq, ioredisMonthly review
Tier 3Mediumshadcn/ui, lucide-react, tailwindcssQuarterly review
Tier 4Loweslint, prettier, typescript (dev-only)Annual review

​
Container Security

​
Build Hardening

Every CaseBender container image follows security best practices: 
Multi-Stage Build → Non-Root User → Alpine Base → Pinned Versions → Frozen Lockfile → No Secrets
  • Multi-stage builds: Build dependencies (compilers, dev tools) are excluded from production images
  • Non-root users: Each service runs as a dedicated non-root user inside the container
  • Alpine Linux: Minimal base images reduce attack surface
  • Pinned tool versions: System packages and global tools are version-pinned
  • No embedded secrets: All secrets are injected at runtime

​
Container Scanning

Every container image is scanned with Trivy for:
  • OS vulnerabilities: CVEs in Alpine packages
  • Application vulnerabilities: CVEs in Node.js dependencies
  • Misconfigurations: Dockerfile best practice violations
  • Secrets: Embedded credentials or API keys
Scans run on every PR and block merges if CRITICAL or HIGH vulnerabilities are found.

​
Image Signing

All 7 CaseBender container images are cryptographically signed using Cosign with keyless signing via Sigstore:

​
Signed Images

ImageRegistry
casebender/webGoogle Artifact Registry
casebender/apiGoogle Artifact Registry
casebender/ingestionGoogle Artifact Registry
casebender/workerGoogle Artifact Registry
casebender/workflow-processorGoogle Artifact Registry
casebender/misp-processorGoogle Artifact Registry
casebender/search-syncGoogle Artifact Registry

​
Verification

Before deployment, our CI/CD pipeline verifies:
  1. Signature Verification: Cosign verifies the image signature against the Sigstore transparency log
  2. SBOM Attestation: Verifies that a signed SBOM is attached to the image
  3. Vulnerability Scan: Final Trivy scan for CRITICAL vulnerabilities
  4. Provenance Check: Verifies SLSA provenance attestation exists
You can verify any CaseBender image signature yourself using:
cosign verify --certificate-identity-regexp="github.com/casebender" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  REGISTRY/casebender/web:TAG

​
SBOM (Software Bill of Materials)

Every release includes a signed Software Bill of Materials in CycloneDX format:
  • Generated by: Trivy SBOM scanner
  • Format: CycloneDX JSON
  • Signed with: Cosign (keyless via Sigstore)
  • Attached to: Each container image as an attestation
  • Retention: 3 years (aligned with compliance requirements)
The SBOM documents every component in the container image:
  • Node.js runtime version
  • All npm packages with exact versions
  • Alpine Linux packages
  • System libraries and their versions

​
SLSA Provenance

CaseBender generates SLSA Level 2+ build provenance for every release:

​
What Provenance Documents

FieldContent
SourceGit commit SHA, repository URL, branch
BuilderGitHub Actions workflow, runner environment
Build ConfigWorkflow file path, trigger event
ArtifactsContainer image digests for all 7 services
MetadataBuild timestamp, actor, invocation ID

​
Provenance Security

  • Provenance documents are signed with Cosign (keyless via Sigstore)
  • Signatures are verified after generation
  • Provenance is retained for 3 years
  • Provenance can be independently verified against the Sigstore transparency log

​
Pre-Deployment Verification

Before any deployment, two verification scripts run as mandatory gates:

​
Reproducible Build Verification

Checks that the build environment is consistent and secure:
  • Lockfile integrity (pnpm-lock.yaml exists and is valid)
  • Node.js version matches expected version (20.x)
  • pnpm version matches expected version (9.15.0)
  • .npmrc security settings are present (save-exact, audit)
  • No suspicious postinstall scripts in dependencies
  • Version pinning files (.nvmrc, .node-version) are present

​
Image Verification

Checks that container images are authentic and safe:
  • Cosign signature verification for each image
  • SBOM attestation verification
  • Trivy vulnerability scan (CRITICAL severity)
  • Image provenance check

​
Compliance Mapping

ControlFrameworkCaseBender Implementation
SR-3 Supply Chain ProtectionCMMCDependency pinning, lockfile integrity, reproducible builds
SR-4 ProvenanceCMMCSLSA provenance, image signing, SBOM
SR-11 Component AuthenticityCMMCCosign signature verification, Sigstore transparency
SI-7 Software IntegrityNIST 800-53Image signing, SBOM attestation, build verification
CM-2 Baseline ConfigurationNIST 800-53Pinned versions, frozen lockfiles, reproducible builds
CM-6 Configuration SettingsNIST 800-53.npmrc hardening, Dockerfile best practices