Security Assurance Program

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

Protected Changes

Pull requests to protected branches pass an aggregate security gate before merge.

Layered Testing

Secrets, source code, dependencies, licenses, infrastructure, and all service images are checked using independent tools.

Release Integrity

Release workflows generate SBOMs, provenance, immutable digests, and cryptographic signatures.

Customer Evidence

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:

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; public customers should use the release-specific evidence described in the Security Evidence Guide.

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:

the target is not a placeholder, localhost, or loopback address;
the response identifies a CaseBender web deployment;
the configured test identity produces an authenticated session; and
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 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.

Code Security — scanner configuration, DAST, licenses, and vulnerability management
Supply Chain Security — dependencies, images, SBOMs, signing, and provenance
Security Evidence Guide — evidence types and how to interpret them
Security Architecture — application and deployment security design
Independent Penetration Test Scope — planned manual assessment coverage

Security Overview

Authentication & Access

Compliance Frameworks