> ## 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.
# Security Assurance Program
> How CaseBender tests changes, blocks security regressions, protects release artifacts, and communicates assurance evidence to customers.
## Purpose
CaseBender is used by security teams, so product security is treated as a release requirement rather than a one-time checklist. The Security Assurance Program combines protected development workflows, automated security testing, container and dependency controls, release provenance, documented exceptions, and independent assessment planning.
This section explains:
* which controls run automatically;
* which findings block a change or release;
* what evidence each control produces;
* how exceptions are governed;
* what customers can verify independently; and
* where automated assurance stops.
Security assurance reduces risk; it does not prove that software is vulnerability-free. Workflow badges, scanner reports, SBOMs, and signatures are evidence of specific controls, not security certifications or substitutes for an independent penetration test.
## Assurance at a Glance
Pull requests to protected branches pass an aggregate security gate before merge.
Secrets, source code, dependencies, licenses, infrastructure, and all service images are checked using independent tools.
Release workflows generate SBOMs, provenance, immutable digests, and cryptographic signatures.
Customers can identify the evidence associated with a commit, image digest, or release.
## Secure Change Lifecycle
Every proposed change follows the same high-level lifecycle:
```text theme={null}
Developer change
→ Pull request
→ Build and functional checks
→ Parallel security controls
→ Aggregate Security Gate
→ Protected-branch review and merge
→ Pre-publish image scan
→ Digest-based publication and signing
→ Deployment readiness verification
→ Scheduled reassessment
```
Controls are deliberately layered. For example, dependency risk is evaluated through both the package-manager advisory database and Trivy; container images are scanned after they are built; and deterministic negative controls verify that secret and SAST scanners still reject known-bad fixtures.
## When Controls Run
| Event | Assurance activity |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Pull request to `main` or `production` | Full source, dependency, license, IaC, Dockerfile, and seven-image security gate |
| Push to `main` | Security gate, SBOM generation, and main-branch artifact workflows |
| Published container build | Pre-publish vulnerability scan, immutable digest capture, signature creation, and signature verification |
| Weekly schedule | Full security workflow and authenticated OWASP ZAP staging scan when the required target and test identity are configured |
| Dependency update | The same pull-request gates apply; GitHub Dependency Review is additionally enforced where repository licensing enables it |
The workflow definition, not this page, is the final technical source for exact trigger and tool configuration. Authorized repository reviewers can inspect the [Security Scan workflow](https://github.com/casebender/webapp/actions/workflows/security-scan.yml); public customers should use the release-specific evidence described in the [Security Evidence Guide](/en/security/security-evidence).
## Merge-Blocking Security Gate
The aggregate Security Gate requires the following jobs to succeed on pull requests and pushes:
| Control | Scope | Blocking condition |
| ------------------------ | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| Gitleaks | Current source and full Git history | Detected secret pattern |
| Trivy filesystem scan | Repository and dependency manifests | Unaccepted HIGH or CRITICAL vulnerability with a fix available |
| Trivy container scan | Web, API, ingestion, worker, workflow processor, MISP processor, and search sync images | Unaccepted HIGH or CRITICAL image vulnerability with a fix available |
| Hadolint | All seven Dockerfiles | Dockerfile policy violation |
| Trivy IaC scan | Dockerfiles and Kubernetes configuration | HIGH or CRITICAL security misconfiguration |
| ESLint security rules | Web TypeScript and JavaScript | Security rule error |
| Semgrep | TypeScript, Next.js, OWASP, injection, XSS, secrets, and security-audit rules | ERROR-severity finding or scanner failure |
| License policy | Repository dependencies | Unapproved blocking license or malformed/empty report |
| `pnpm audit` | Production dependencies | HIGH or CRITICAL advisory |
| SBOM generation | Full workspace | CycloneDX generation failure |
| Security control tests | Generated secret and unsafe-code fixtures | Scanner fails to reject a known-bad fixture |
| GitHub Dependency Review | Pull-request dependency delta, when licensed | New HIGH/CRITICAL vulnerability or denied license |
Scanner result uploads may be best-effort when GitHub Code Security is not licensed, but the underlying local scan remains blocking. Reports are also preserved as workflow artifacts so the gate does not depend on SARIF ingestion.
## Dynamic Security Testing
The weekly DAST job uses OWASP ZAP against a dedicated staging deployment. Before active testing starts, CI verifies:
1. the target is not a placeholder, localhost, or loopback address;
2. the response identifies a CaseBender web deployment;
3. the configured test identity produces an authenticated session; and
4. the authentication header is supplied through masked repository secrets.
The scan performs authenticated active testing and preserves its report. Missing targets or credentials cause the DAST job to fail rather than silently scanning an irrelevant page.
DAST coverage is constrained by the routes and state reachable by the test identity. It does not replace manual authorization, tenant-isolation, workflow-abuse, parser, or integration testing.
## Container Assurance
CaseBender currently produces seven service images. Each production Dockerfile uses a multi-stage build and a non-root runtime user. The container assurance path includes:
* Dockerfile linting;
* production dependency pruning;
* vulnerability scanning before publication;
* embedded-secret detection through image scanning;
* immutable digest selection after publication;
* keyless Cosign signing through GitHub's OIDC identity; and
* signature verification against the exact published digest.
Docker Hub and GitHub Container Registry workflows sign the digest that customers pull rather than relying only on mutable tags such as `latest`.
## Software Supply Chain Evidence
Release workflows generate several complementary records:
* **CycloneDX SBOM** — package and component inventory for dependency analysis;
* **BuildKit SBOM and provenance** — build metadata emitted with container builds;
* **Cosign signature** — cryptographic identity bound to an immutable image digest;
* **SBOM attestation** — signed association between an image and its component inventory;
* **SLSA-format provenance document** — source revision, workflow identity, and invocation metadata; and
* **Scanner reports** — SARIF or JSON output retained by the applicable workflow.
The standalone SLSA-format document is signed build metadata. Its current `subject` is empty, so it is not cryptographically bound to the seven image digests and must not be represented as artifact-level provenance or an independent SLSA certification.
## Vulnerability Handling
Findings are triaged according to severity, exploitability, affected deployment mode, exposure, and patch availability. The default remediation targets documented by the project are:
| Severity | Target |
| -------- | -------- |
| Critical | 24 hours |
| High | 7 days |
| Medium | 30 days |
| Low | 90 days |
These are internal remediation targets, not contractual service levels unless incorporated into a customer agreement.
When immediate remediation is not possible, an exception must be narrow and reviewable. Current Trivy IaC exceptions are stored in `.trivyignore.yaml` and include the finding, affected path, justification, and expiry date. License exceptions are package-specific; the policy does not suppress a license identifier globally. The repository file should not be interpreted as a complete register for every category of accepted product risk.
## Tool and Workflow Integrity
The controls themselves are also protected:
* third-party GitHub Actions are pinned to immutable commit SHAs;
* important scanner binaries and container images are version or digest pinned;
* lockfile-based installs use `--frozen-lockfile`;
* security negative controls detect a scanner that unexpectedly stops rejecting known-bad input;
* current GitHub branch-protection settings reject direct updates that have not produced required status checks; this policy is administered outside the source repository; and
* aggregate jobs fail if a required security job is failed, cancelled, or unexpectedly skipped.
### Supplementary Malware Heuristic
A separate post-merge workflow monitors changes to Next.js and PostCSS configuration files on `main` for known malicious npm supply-chain patterns and can create an automated revert. This is a narrow, pattern-based recovery control. It is not a pull-request gate, antivirus engine, EDR control, or comprehensive malware scan.
## Customer Responsibilities
CaseBender is deployable on customer-managed infrastructure. Product assurance does not replace secure operation of that environment. Customers remain responsible for:
* TLS certificates, ingress, firewall, and network segmentation;
* identity-provider, MFA, and role configuration;
* database, Redis, object-storage, and search-service hardening;
* secret rotation and access to deployment credentials;
* backups, monitoring, retention, and incident response;
* applying supported updates and reviewing release notes; and
* validating controls against their regulatory and threat environment.
See the [Deployment Hardening Guide](/en/security/hardening-guide) for operational recommendations.
## Current Assurance Boundaries
As of July 2026:
* automated SAST, SCA, secret, license, IaC, container, SBOM, signing, and provenance workflows are implemented;
* authenticated staging DAST is configured in CI but depends on a maintained staging target and test identity;
* GitHub-hosted SARIF and Dependency Review features depend on repository licensing, while local Trivy and package-audit gates remain available;
* no completed third-party penetration-test report or remediation retest letter is claimed; and
* compliance mappings describe control alignment, not an independent certification.
The proposed independent assessment scope is documented in [Independent Penetration Test Scope](/en/security/penetration-test-scope).
## Related Documentation
* [Code Security](/en/security/code-security) — scanner configuration, DAST, licenses, and vulnerability management
* [Supply Chain Security](/en/security/supply-chain) — dependencies, images, SBOMs, signing, and provenance
* [Security Evidence Guide](/en/security/security-evidence) — evidence types and how to interpret them
* [Security Architecture](/en/security/architecture) — application and deployment security design
* [Independent Penetration Test Scope](/en/security/penetration-test-scope) — planned manual assessment coverage