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
Traceability Procedure
1. Record the deployed digest
Use the registry or container runtime to capture the immutable digest:
Expected output resembles:
2. Verify the signature
CaseBender release workflows use keyless Cosign signing backed by GitHub Actions OIDC:
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.
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.
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:
- release identifier and commit SHA;
- immutable digests for the deployed service images;
- Security Gate workflow result;
- container scan results for those digests;
- CycloneDX SBOMs;
- signature-verification output;
- signed provenance and verification output;
- applicable active exception records;
- a vulnerability-remediation summary; and
- 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.
Reporting a Security Concern
Report suspected CaseBender vulnerabilities to 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
