> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Supply Chain Security

> How CaseBender secures its build pipeline with dependency management, container signing, SBOM generation, and SLSA provenance.

## 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

| Pipeline            | Status                                                                                                                | Runs On                       |
| ------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------- |
| Security Scan       | ![Security Scan](https://github.com/casebender/webapp/actions/workflows/security-scan.yml/badge.svg?branch=main)      | Every PR and push to main     |
| Supply Chain Verify | ![Supply Chain](https://github.com/casebender/webapp/actions/workflows/supply-chain-verify.yml/badge.svg?branch=main) | Every PR and push to main     |
| Image Signing       | ![Image Signing](https://github.com/casebender/webapp/actions/workflows/image-sign.yml/badge.svg?branch=main)         | Every push to main/production |
| SLSA Provenance     | ![SLSA Provenance](https://github.com/casebender/webapp/actions/workflows/slsa-provenance.yml/badge.svg?branch=main)  | Every 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](https://docs.github.com/en/code-security/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 7 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

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:

| 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 container image is scanned with [Trivy](https://trivy.dev/) 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](https://docs.sigstore.dev/cosign/overview/) with keyless signing via [Sigstore](https://www.sigstore.dev/):

### Signed Images

| Image                           | Registry                 |
| ------------------------------- | ------------------------ |
| `casebender/web`                | Google Artifact Registry |
| `casebender/api`                | Google Artifact Registry |
| `casebender/ingestion`          | Google Artifact Registry |
| `casebender/worker`             | Google Artifact Registry |
| `casebender/workflow-processor` | Google Artifact Registry |
| `casebender/misp-processor`     | Google Artifact Registry |
| `casebender/search-sync`        | Google 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

<Tip>
  You can verify any CaseBender image signature yourself using:

  ```bash theme={null}
  cosign verify --certificate-identity-regexp="github.com/casebender" \
    --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
    REGISTRY/casebender/web:TAG
  ```
</Tip>

## SBOM (Software Bill of Materials)

Every release includes a signed Software Bill of Materials in [CycloneDX](https://cyclonedx.org/) 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](https://slsa.dev/) Level 2+ build provenance for every release:

### 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           |
| **Artifacts**    | Container image digests for all 7 services  |
| **Metadata**     | Build 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

| 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               |

## Related Documentation

* [Code Security](/en/security/code-security) — SAST, DAST, and vulnerability management
* [Security Overview](/en/security/overview) — Live pipeline status badges
* [Hardening Guide](/en/security/hardening-guide) — Deployment security recommendations