Skip to main content

​
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:
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.