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

# Sécurité des versions de stockage

> Qualification de version, revue SBOM et preuves de stockage signées

Le support du stockage est qualifié par version CaseBender, adaptateur
fournisseur et profil de déploiement. Un nom de fournisseur seul n'est pas
une preuve suffisante.

## Porte de version

Avant de publier une version on-premises ou OpenShift :

1. Épinglez chaque image par digest dans le manifeste de version.
2. Générez un SBOM CycloneDX ou SPDX pour chaque image et le lot source.
3. Signez les images et attestez les SBOM avec l'identité de version.
4. Analysez les digests exacts publiés/miroités, y compris les paquets OS
   et de langage.
5. Examinez les SDK de stockage, les bibliothèques TLS, les lots CA et les
   dépendances transitives.
6. Exécutez les tests de contrat fournisseur, d'intégrité, de migration,
   de sauvegarde/restauration et de rollback pour chaque fournisseur listé
   comme supporté par cette version.
7. Enregistrez les exceptions avec propriétaire, exploitabilité, contrôle
   compensatoire, expiration et approbation. Ne supprimez pas une famille
   de paquets entière.

Les workflows de version du dépôt produisent déjà des preuves SBOM et de
signature, et `deploy/verify-images.sh` vérifie les signatures d'image, les
attestations CycloneDX et la politique de vulnérabilités. Utilisez ces
contrôles contre chaque digest après miroir ainsi qu'avant l'export.

## Vérification consommateur

Obtenez le manifeste de version, les sommes de contrôle, la politique
d'identité/émetteur Sigstore, les SBOM et les attestations via un canal de
confiance séparé. Puis :

```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>
```

Utilisez l'identité et l'émetteur exacts des notes de version signées, pas
ces espaces réservés. Un échec de vérification est un bloqueur de version.
Préservez les preuves du journal de transparence lorsque vous êtes
connecté ; pour une vérification déconnectée, transférez le lot signé et
le matériel de confiance public via le processus approuvé.

## Revue SBOM spécifique au stockage

Confirmez que le SBOM contient les adaptateurs sélectionnés à l'exécution
et examinez :

* les composants MinIO historiques uniquement dans les artefacts
  source/reprise héritage ; l'exécution de production ne doit pas contenir
  le paquet natif `minio` ;
* `@aws-sdk/client-s3` pour S3 ; une dépendance presigner ne doit pas
  impliquer un comportement d'URL signées activé ;
* `@google-cloud/storage` et les bibliothèques d'authentification pour GCS ;
* `@azure/storage-blob` et `@azure/identity` pour Azure ;
* Node.js/OpenSSL et le lot CA de l'image ;
* les images CLI/outils utilisées pour la sauvegarde, la migration et la
  validation.

Un adaptateur installé mais non sélectionné contribue toujours au risque de
paquet atteignable et doit rester dans la revue SBOM et de vulnérabilités.
Inversement, la présence dans le SBOM ne prouve pas qu'un produit/une
version est certifié. Azure est implémenté sous l'ID d'exécution canonique
`azure`, mais la matrice actuelle ne déclare pas `azure-blob` comme
supporté par la version.

## Enregistrement de preuves de version

Conservez :

* la révision source, les digests d'image immuables, les hachages SBOM,
  les signatures et la sortie de vérification ;
* les bases de données/versions d'outils du scanner et les exceptions de
  vulnérabilités approuvées ;
* les versions fournisseur/produit, le protocole/chiffre/émetteur TLS du
  point de terminaison et le hachage CA ;
* les résultats de contrat fournisseur assainis et d'intégrité SHA-256 ;
* les journaux de copie/vérification de migration et le résultat de
  rollback ;
* le point de cohérence de sauvegarde, le test de restauration, le RPO/RTO
  mesuré ;
* la version OpenShift, la revue SCC, les manifestes rendus, les versions
  CNI/CSI et les tests d'écriture `/tmp`/`/data` UID arbitraire.

N'incluez jamais de clés d'accès, de valeurs secrètes, d'URL pré-signées,
de clés privées, d'URL de base de données, de noms d'objets client ou de
contenus d'objets dans les preuves de version ou les lots de support.

## Réponse de sécurité

Lorsqu'une vulnérabilité de SDK de stockage ou de fournisseur est divulguée,
déterminez si le code et la configuration concernés sont présents et
atteignables, publiez un avis ciblé, mettez à jour les images/SBOM
affectés et relancez les tests de contrat et de restauration. Le retrait
d'un fournisseur est une décision de cycle de vie produit avec un avis
explicite, un guide de migration et des dates de support. Le guide
CaseBender actuel traite un déploiement MinIO héritage uniquement comme
source externe de migration/rollback ; cette politique n'invente pas de
date de fin de support client au-delà d'un plan de changement client
approuvé.