Supply Chain Security

Overview

CaseBender’s supply-chain workflows combine dependency controls, image scanning, SBOM generation, digest-based signing, and provenance. Vulnerability gates run before publication; signing and attestation coverage depends on the registry channel and release workflow described below.

Pipeline Workflows

Pipeline	Runs On
Security Scan	Every pull request to `main` or `production`, push to `main`, and weekly schedule
Supply Chain Verify	Every pull request and push to `main` or `production`
Main Image Build	Relevant pushes to `main` and manual edge builds
On-Premises Release	SemVer tag pushes and recovery runs for existing release tags

GitHub workflow badge images are not publicly readable for this private repository and return 404 Not Found when embedded without an authorized GitHub session. Authorized reviewers can use the links above; public assurance should rely on release-specific signatures, SBOMs, provenance metadata, and provided reports.

Stable publication starts from a protected SemVer Git tag. Manual workflow dispatch is recovery-only: it must run from main, requires an existing release tag, reuses that tag’s signed candidate digests, and cannot create a new release from arbitrary branch contents.

Dependency Management

Resolution Control

The lockfile records exact resolved dependency versions, while some package manifests retain compatible version ranges:

save-exact=true in .npmrc makes newly added dependencies exact by default
strict-peer-dependencies=false is currently required for documented React 19 peer-range incompatibilities; CI still reports peer warnings
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:

Ecosystem	Schedule	Scope
npm	Weekly (Monday)	Production deps, dev deps, OpenTelemetry, Prisma (grouped)
Docker	Weekly (Tuesday)	Base images for all 8 services
GitHub Actions	Weekly (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

When GitHub Code Security is licensed and ENABLE_CODE_SCANNING is enabled, pull-request dependency deltas are 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)

Without that repository feature, the merge-blocking Trivy filesystem scan, production pnpm audit, and license-policy job remain active.

Approved Component Registry

CaseBender maintains a documented registry of approved third-party components organized by risk tier:

Tier	Risk Level	Examples	Review Frequency
Tier 1	Critical	next-auth, prisma, bcrypt, jose	Every update reviewed
Tier 2	High	tRPC, zod, bullmq, ioredis	Monthly review
Tier 3	Medium	shadcn/ui, lucide-react, tailwindcss	Quarterly review
Tier 4	Low	eslint, 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 service image built by the pull-request security workflow is scanned locally 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

CaseBender uses Cosign keyless signing through Sigstore for customer-facing Docker Hub publications. Main builds publish SHA and edge tags. Only the release workflow can promote stable SemVer and latest tags.

Signed Images

Image	Signed publication channels
`casebender/casebender`	Docker Hub main and stable release channels
`casebender/api`	Docker Hub main and stable release channels
`casebender/ingestion`	Docker Hub main and stable release channels
`casebender/worker`	Docker Hub main and stable release channels
`casebender/workflow-processor`	Docker Hub main and stable release channels
`casebender/connector-worker`	Docker Hub main and stable release channels
`casebender/misp-processor`	Docker Hub main and stable release channels
`casebender/search-sync`	Docker Hub main and stable release channels

Google Artifact Registry is used by the managed Cloud Run deployment workflow. Its signature-verification step is currently report-only during the SEC-019 rollout and must not be represented as a blocking signed-deployment gate.

Verification

Across the signed publication workflows, controls include:

Signature Verification: Cosign verifies the image signature against the Sigstore transparency log
SBOM and provenance attestations: BuildKit binds generated attestations to the image digest
Vulnerability Scan: Final Trivy scan for CRITICAL vulnerabilities

You can verify any CaseBender image signature yourself using:

cosign verify \
  --certificate-identity="https://github.com/casebender/webapp/.github/workflows/release-onprem.yml@refs/tags/vX.Y.Z" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  casebender/casebender@sha256:DIGEST

SBOM (Software Bill of Materials)

Every release image includes a BuildKit-generated SBOM attestation:

Generated by: Docker BuildKit
Bound to: The immutable image digest
Protected by: Registry provenance plus the digest’s Cosign signature
Release evidence: The customer bundle records all seven signed digests

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

Docker BuildKit emits artifact-bound provenance (mode=max) for each published image. This replaces the former standalone metadata document whose subject was not bound to an image.

What Provenance Documents

Field	Content
Source	Git commit SHA, repository URL, branch
Builder	GitHub Actions workflow, runner environment
Build Config	Workflow file path, trigger event
Subject	Immutable container image digest
Metadata	Build timestamp, actor, invocation ID

Provenance Security

Provenance and SBOM attestations are emitted during the image build
Cosign signs the exact digest after vulnerability scanning
The release workflow verifies every signature before tag promotion
The signed customer bundle contains a manifest mapping each service to its digest

Pre-Deployment Verification

The Cloud deployment workflow runs reproducibility and image-verification checks before deployment. Their current enforcement differs:

Reproducible Build Verification

This is a required job and checks that the build environment is consistent:

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

The main and on-premises release workflows enforce image authenticity and safety before their public aliases move:

Hadolint Dockerfile policy
Trivy CRITICAL/HIGH vulnerability gate
BuildKit SBOM and provenance attestations
Cosign digest signing and exact workflow-identity verification
post-promotion digest verification

Compliance Mapping

Control	Framework	CaseBender Implementation
SR-3 Supply Chain Protection	CMMC	Dependency pinning, lockfile integrity, reproducible builds
SR-4 Provenance	CMMC	SLSA provenance, image signing, SBOM
SR-11 Component Authenticity	CMMC	Cosign signature verification, Sigstore transparency
SI-7 Software Integrity	NIST 800-53	Image signing, SBOM attestation, build verification
CM-2 Baseline Configuration	NIST 800-53	Pinned versions, frozen lockfiles, reproducible builds
CM-6 Configuration Settings	NIST 800-53	`.npmrc` hardening, Dockerfile best practices

Security Assurance Program — Control lifecycle, enforcement, and assurance boundaries
Code Security — SAST, DAST, and vulnerability management
Security Evidence Guide — Digest traceability, signature verification, and evidence interpretation
Security Overview — Live pipeline status badges
Hardening Guide — Deployment security recommendations

Security Overview

Authentication & Access

Compliance Frameworks

Security Assurance

Operations

Supply Chain Security

Overview

Pipeline Workflows

Dependency Management

Resolution Control

Automated Dependency Updates

Dependency Review

Approved Component Registry

Container Security

Build Hardening

Container Scanning

Image Signing

Signed Images

Verification

SBOM (Software Bill of Materials)

SLSA Provenance

What Provenance Documents

Provenance Security

Pre-Deployment Verification

Reproducible Build Verification

Image Verification

Compliance Mapping

​Overview

​Pipeline Workflows

​Dependency Management

​Resolution Control

​Automated Dependency Updates

​Dependency Review

​Approved Component Registry

​Container Security

​Build Hardening

​Container Scanning

​Image Signing

​Signed Images

​Verification

​SBOM (Software Bill of Materials)

​SLSA Provenance

​What Provenance Documents

​Provenance Security

​Pre-Deployment Verification

​Reproducible Build Verification

​Image Verification

​Compliance Mapping

​Related Documentation

Overview

Pipeline Workflows

Dependency Management

Resolution Control

Automated Dependency Updates

Dependency Review

Approved Component Registry

Container Security

Build Hardening

Container Scanning

Image Signing

Signed Images

Verification

SBOM (Software Bill of Materials)

SLSA Provenance

What Provenance Documents

Provenance Security

Pre-Deployment Verification

Reproducible Build Verification

Image Verification

Compliance Mapping

Related Documentation