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

# Storage release security

# Storage release security and SBOM evidence

Storage support is qualified per CaseBender release, provider adapter, and
deployment profile. A provider name alone is not sufficient evidence.

## Release gate

Before publishing an on-premises or OpenShift release:

1. Pin every image by digest in the release manifest.
2. Generate a CycloneDX or SPDX SBOM for each image and the source bundle.
3. Sign images and attest SBOMs with the release identity.
4. Scan the exact published/mirrored digests, including OS and language packages.
5. Review storage SDKs, TLS libraries, CA bundles, and transitive dependencies.
6. Run provider contract, integrity, migration, backup/restore, and rollback
   tests for every provider listed as supported by that release.
7. Record exceptions with owner, exploitability, compensating control, expiry,
   and approval. Do not suppress an entire package family.

The repository's release workflows already produce SBOM and signature evidence,
and `deploy/verify-images.sh` verifies image signatures, CycloneDX attestations,
and vulnerability policy. Use those controls against each digest after mirroring
as well as before export.

## Consumer verification

Obtain the release manifest, checksums, Sigstore identity/issuer policy, SBOMs,
and attestations through a separate trusted channel. Then:

```sh theme={null}
cosign verify \
  --certificate-identity-regexp '<approved-release-identity>' \
  --certificate-oidc-issuer '<approved-issuer>' \
  registry.example.com/casebender/webapp@sha256:<digest>

cosign verify-attestation \
  --type cyclonedx \
  --certificate-identity-regexp '<approved-release-identity>' \
  --certificate-oidc-issuer '<approved-issuer>' \
  registry.example.com/casebender/webapp@sha256:<digest>

trivy image --severity HIGH,CRITICAL \
  registry.example.com/casebender/webapp@sha256:<digest>
```

Use the exact identity and issuer from signed release notes, not these
placeholders. Verification failure is a release blocker. Preserve transparency
log evidence when connected; for disconnected verification, transfer the signed
bundle and public trust material through the approved process.

## Storage-specific SBOM review

Confirm the SBOM contains the adapters selected at runtime and review:

* `minio` and its HTTP/TLS dependencies for the native MinIO provider;
* `@aws-sdk/client-s3` and `@aws-sdk/s3-request-presigner` for S3;
* `@google-cloud/storage` and authentication libraries for GCS;
* Node.js/OpenSSL and the image CA bundle;
* CLI/tool images used for backup, migration, and validation.

An installed but unselected adapter still contributes reachable package risk and
must remain in SBOM and vulnerability review. Conversely, SBOM presence does not
prove a provider is implemented: Azure remains unsupported until a provider,
contract tests, operations guidance, and release qualification exist.

## Release evidence record

Retain:

* source revision, immutable image digests, SBOM hashes, signatures, and
  verification output;
* scanner databases/tool versions and approved vulnerability exceptions;
* provider/product versions, endpoint TLS protocol/cipher/issuer, and CA hash;
* sanitized provider contract and SHA-256 integrity results;
* migration copy/check logs and rollback result;
* backup consistency point, restore test, measured RPO/RTO;
* OpenShift version, SCC review, rendered manifests, CNI/CSI versions, and
  arbitrary-UID `/tmp`/`/data` write tests.

Never include access keys, secret values, presigned URLs, private keys, database
URLs, customer object names, or object contents in release evidence or support
bundles.

## Security response

When a storage SDK or provider vulnerability is disclosed, determine whether the
affected code and configuration are present and reachable, publish a scoped
advisory, update affected images/SBOMs, and re-run contract and restore tests.
Provider retirement is a product lifecycle decision with explicit notice,
migration guidance, and support dates; no retirement date for MinIO is asserted
by this policy.