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

> A guide for customers reviewing CaseBender scanner reports, SBOMs, signatures, provenance, exceptions, and assessment status.

## Overview

Security evidence is most useful when it can be traced to the exact software a customer is evaluating. CaseBender identifies builds by Git commit and identifies container artifacts by immutable digest.

For an assurance review, begin with one of:

* a CaseBender release version;
* the Git commit SHA shown by the release;
* the digest of each deployed container image; or
* the workflow run that produced the artifacts.

Tags such as `latest` are convenient references but are not stable evidence identifiers.

## Evidence Catalog

| Evidence                        | What it demonstrates                                                  | Important limitation                                                                      |
| ------------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Security Gate result            | Required CI security jobs completed successfully for a revision       | Covers configured automated controls only                                                 |
| Gitleaks report/log             | No matching secret pattern remained in the scanned source and history | Cannot identify every possible credential format                                          |
| Trivy filesystem SARIF          | Dependency findings for the scanned repository state                  | Advisory databases and package detection change over time                                 |
| Trivy container SARIF           | OS and application findings in a built service image                  | Applies only to the scanned digest                                                        |
| Trivy IaC SARIF                 | Findings in Docker and Kubernetes configuration                       | Does not validate every runtime platform setting                                          |
| Semgrep SARIF                   | Findings from configured source and taint-analysis rules              | Rule coverage is not equivalent to manual code review                                     |
| Dependency audit JSON           | Production dependency advisories known to the package registry        | Does not cover operating-system packages                                                  |
| License JSON and policy result  | Detected licenses and package-specific policy decisions               | Legal interpretation remains customer-specific                                            |
| CycloneDX SBOM                  | Components detected for a repository or image                         | An SBOM is an inventory, not a vulnerability-free statement                               |
| Cosign signature                | A workflow identity signed a specific image digest                    | Signature verification does not assess application behavior                               |
| SBOM attestation                | A signed SBOM is associated with a specific image                     | The attestation is only as accurate as SBOM generation                                    |
| SLSA-format provenance document | Source revision and build invocation metadata                         | Current `subject` is empty; it is not bound to an image digest or independently certified |
| OWASP ZAP report                | Results from the authenticated staging routes reached by ZAP          | Does not prove complete API or business-logic coverage                                    |
| Exception record                | A finding was intentionally scoped, justified, and given an expiry    | Does not eliminate the underlying risk                                                    |

## Traceability Procedure

### 1. Record the deployed digest

Use the registry or container runtime to capture the immutable digest:

```bash theme={null}
docker image inspect IMAGE:TAG \
  --format='{{index .RepoDigests 0}}'
```

Expected output resembles:

```text theme={null}
registry.example.com/casebender/web@sha256:...
```

### 2. Verify the signature

CaseBender release workflows use keyless Cosign signing backed by GitHub Actions OIDC:

```bash theme={null}
cosign verify \
  --certificate-identity-regexp='https://github.com/casebender/webapp/' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
  IMAGE@sha256:DIGEST
```

Verification should be performed against a digest, not only a tag. The registry channel and certificate identity must match the release documentation supplied with the artifact.

### 3. Verify provenance metadata

Review the provenance document for:

* repository and source revision;
* workflow identity and trigger;
* build timestamp and actor;
* the `subject` field and whether it identifies the artifact under review; and
* the attached signature and signing certificate.

<Warning>
  The current standalone CaseBender provenance document has an empty `subject`. It can be verified as signed workflow metadata, but it cannot currently prove that a particular container digest was produced by that invocation. Use the registry digest, image signature, and image SBOM attestation for artifact-level traceability.
</Warning>

Verify the signed blob before relying on its content:

```bash theme={null}
cosign verify-blob \
  --signature provenance.json.sig \
  --certificate provenance.json.cert \
  --certificate-identity-regexp='https://github.com/casebender/webapp/' \
  --certificate-oidc-issuer='https://token.actions.githubusercontent.com' \
  provenance.json
```

### 4. Review the SBOM

Use the SBOM to identify direct and transitive components relevant to your deployment. Customers may import CycloneDX JSON into their own vulnerability-management or software-asset tools.

An SBOM should be matched to the same commit or image digest under review. A repository-level SBOM and an image-level SBOM answer different questions and should not be treated as interchangeable.

### 5. Review security findings and exceptions

Confirm:

* the scan completed rather than being skipped;
* the report corresponds to the target revision or digest;
* the severity policy used by the workflow;
* whether unfixed findings were excluded by the scanner configuration;
* whether an exception applies to the exact finding and path; and
* whether the exception is still within its review period.

## Artifact Retention

Current workflow retention settings include:

* scanner and audit artifacts: generally 30 days;
* repository CycloneDX SBOM artifacts and signing material: 1,095 days; and
* registry signatures and attestations: retained with the applicable registry artifact, subject to registry lifecycle policy.

Retention in a customer's own environment is controlled by that customer. Customers with longer audit requirements should archive the evidence package received for each deployed release.

## Suggested Customer Evidence Package

For a release assurance review, the relevant package may include:

1. release identifier and commit SHA;
2. immutable digests for the deployed service images;
3. Security Gate workflow result;
4. container scan results for those digests;
5. CycloneDX SBOMs;
6. signature-verification output;
7. signed provenance and verification output;
8. applicable active exception records;
9. a vulnerability-remediation summary; and
10. the current penetration-testing status statement.

Availability may depend on repository permissions, registry channel, artifact-retention windows, and contractual disclosure terms. Raw reports can contain repository paths, dependency details, or infrastructure information and may require secure transfer or redaction.

## Interpreting a Successful Result

A green workflow means the configured jobs completed according to the policy encoded at that revision. It does not mean:

* no vulnerability exists;
* every application path was tested;
* all deployed infrastructure matches the scanned templates;
* every dependency is free of future advisories;
* a third party independently validated the result; or
* the release is certified against a compliance framework.

For higher-assurance deployments, combine automated evidence with architecture review, customer-environment hardening, threat modeling, and independent manual testing.

## Penetration-Test Evidence

CaseBender does not currently claim a completed third-party penetration-test report or remediation retest letter. Automated ZAP testing and the in-product penetration-test management capability are not substitutes for that evidence.

The planned engagement, required tester qualifications, rules of engagement, and expected deliverables are documented in [Independent Penetration Test Scope](/en/security/penetration-test-scope).

## Reporting a Security Concern

Report suspected CaseBender vulnerabilities to [security@casebender.com](mailto:security@casebender.com). Include:

* affected version or image digest;
* deployment mode;
* reproducible steps;
* expected and observed behavior;
* potential impact; and
* any proof-of-concept material suitable for secure handling.

Do not include active credentials, customer data, or destructive exploit material in an initial unencrypted message.

## Related Documentation

* [Security Assurance Program](/en/security/security-assurance)
* [Code Security](/en/security/code-security)
* [Supply Chain Security](/en/security/supply-chain)
* [Deployment Hardening Guide](/en/security/hardening-guide)