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

# Seguridad de la versión de almacenamiento

> Cualificación de la versión, revisión de SBOM y evidencia de almacenamiento firmada

El soporte de almacenamiento se cualifica por versión de CaseBender,
adaptador de proveedor y perfil de implementación. Un nombre de
proveedor por sí solo no es evidencia suficiente.

## Puerta de la versión

Antes de publicar una versión on-premises u OpenShift:

1. Fije cada imagen por digest en el manifiesto de la versión.
2. Genere un SBOM CycloneDX o SPDX para cada imagen y el paquete de
   código fuente.
3. Firme las imágenes y ateste los SBOM con la identidad de la
   versión.
4. Escanee los digests exactos publicados/reflejados, incluidos los
   paquetes de SO y de lenguaje.
5. Revise los SDK de almacenamiento, las bibliotecas TLS, los
   paquetes de CA y las dependencias transitivas.
6. Ejecute pruebas de contrato del proveedor, integridad, migración,
   copia de seguridad/restauración y reversión para cada proveedor
   listado como soportado por esa versión.
7. Registre las excepciones con propietario, explotabilidad, control
   compensatorio, caducidad y aprobación. No suprima una familia
   entera de paquetes.

Los flujos de trabajo de versión del repositorio ya producen
evidencia de SBOM y firmas, y `deploy/verify-images.sh` verifica las
firmas de imagen, las atestaciones CycloneDX y la política de
vulnerabilidades. Use esos controles contra cada digest después de
reflejarlo, además de antes de la exportación.

## Verificación del consumidor

Obtenga el manifiesto de la versión, los checksums, la política de
identidad/emisor de Sigstore, los SBOM y las atestaciones a través
de un canal de confianza separado. A continuación:

```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 la identidad y el emisor exactos de las notas de versión
firmadas, no estos marcadores. Un fallo de verificación es un
bloqueador de la versión. Conserve la evidencia del registro de
transparencia cuando esté conectado; para la verificación
desconectada, transfiera el paquete firmado y el material de
confianza pública mediante el proceso aprobado.

## Revisión de SBOM específica del almacenamiento

Confirme que el SBOM contiene los adaptadores seleccionados en
tiempo de ejecución y revise:

* componentes históricos de MinIO solo en artefactos de origen/
  recuperación heredados; el tiempo de ejecución de producción no
  debe contener el paquete nativo `minio`;
* `@aws-sdk/client-s3` para S3; una dependencia de presigner no
  debe implicar el comportamiento de URL firmadas habilitado;
* `@google-cloud/storage` y las bibliotecas de autenticación para
  GCS;
* `@azure/storage-blob` y `@azure/identity` para Azure;
* Node.js/OpenSSL y el paquete de CA de la imagen;
* imágenes de CLI/herramientas usadas para copia de seguridad,
  migración y validación.

Un adaptador instalado pero no seleccionado sigue aportando riesgo
de paquete alcanzable y debe permanecer en la revisión de SBOM y
vulnerabilidades. A la inversa, la presencia en el SBOM no
demuestra que un producto/versión esté certificado. Azure está
implementado bajo el identificador canónico de tiempo de ejecución
`azure`, pero la matriz actual no declara `azure-blob` como
soportado en la versión.

## Registro de evidencia de la versión

Conserve:

* la revisión del código fuente, los digests inmutables de imagen,
  los hashes de SBOM, las firmas y la salida de verificación;
* las bases de datos/versiones de herramientas del escáner y las
  excepciones de vulnerabilidad aprobadas;
* las versiones de proveedor/producto, el protocolo/cifrado/emisor
  TLS del endpoint y el hash de CA;
* los resultados saneados del contrato del proveedor y de
  integridad SHA-256;
* los registros de copia/comprobación de migración y el resultado
  de la reversión;
* el punto de consistencia de la copia de seguridad, la prueba de
  restauración, el RPO/RTO medido;
* la versión de OpenShift, la revisión de SCC, los manifiestos
  renderizados, las versiones de CNI/CSI y las pruebas de
  escritura de UID arbitrario en `/tmp`/`/data`.

Nunca incluya claves de acceso, valores secretos, URL prefirmadas,
claves privadas, URL de base de datos, nombres de objeto del
cliente ni contenidos de objeto en la evidencia de la versión o en
los paquetes de soporte.

## Respuesta de seguridad

Cuando se divulgue una vulnerabilidad del SDK de almacenamiento o
del proveedor, determine si el código y la configuración afectados
están presentes y son alcanzables, publique un aviso acotado,
actualice las imágenes/SBOM afectados y vuelva a ejecutar las
pruebas de contrato y restauración. La retirada de un proveedor es
una decisión de ciclo de vida del producto con aviso explícito,
guía de migración y fechas de soporte. La guía actual de CaseBender
trata una implementación MinIO heredada solo como origen externo
de migración/reversión; esta política no inventa una fecha de fin
de soporte del cliente más allá de un plan de cambio aprobado del
cliente.