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

# Sicurezza della release dello storage

> Qualificazione della release, revisione SBOM ed evidenze di storage firmate

Il supporto dello storage è qualificato per release CaseBender, adapter del provider e
profilo di distribuzione. Un nome di provider da solo non è evidenza sufficiente.

## Gate della release

Prima di pubblicare una release on-premises o OpenShift:

1. Fissa ogni immagine per digest nel manifesto della release.
2. Genera un SBOM CycloneDX o SPDX per ciascuna immagine e per il bundle sorgente.
3. Firma le immagini e attesta gli SBOM con l'identità della release.
4. Scansiona i digest pubblicati/mirrorati esatti, inclusi i pacchetti OS e di linguaggio.
5. Rivedi gli SDK di storage, le librerie TLS, i bundle CA e le dipendenze transitive.
6. Esegui i test di contratto del provider, integrità, migrazione, backup/ripristino e
   rollback per ogni provider elencato come supportato da quella release.
7. Registra le eccezioni con owner, exploitability, controllo compensativo, scadenza
   e approvazione. Non sopprimere un'intera famiglia di pacchetti.

I workflow di release del repository producono già evidenze SBOM e di firma,
e `deploy/verify-images.sh` verifica le firme delle immagini, le attestazioni CycloneDX
e la policy sulle vulnerabilità. Usa tali controlli contro ciascun digest dopo il mirroring
oltre che prima dell'export.

## Verifica del consumatore

Ottieni il manifesto della release, i checksum, la policy di identità/issuer Sigstore, gli SBOM
e le attestazioni attraverso un canale fidato separato. Quindi:

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

Usa l'identità e l'issuer esatti dalle note di release firmate, non questi
placeholder. Un fallimento di verifica è un blocco della release. Conserva le evidenze del
transparency log quando connesso; per la verifica disconnessa, trasferisci il bundle
firmato e il materiale di trust pubblico attraverso il processo approvato.

## Revisione SBOM specifica dello storage

Conferma che lo SBOM contenga gli adapter selezionati a runtime e rivedi:

* componenti MinIO storici solo negli artefatti sorgente/recovery legacy; il
  runtime di produzione non deve contenere il pacchetto nativo `minio`;
* `@aws-sdk/client-s3` per S3; una dipendenza presigner non deve implicare il
  comportamento di URL firmati abilitato;
* `@google-cloud/storage` e le librerie di autenticazione per GCS;
* `@azure/storage-blob` e `@azure/identity` per Azure;
* Node.js/OpenSSL e il bundle CA dell'immagine;
* immagini CLI/strumenti usate per backup, migrazione e validazione.

Un adapter installato ma non selezionato contribuisce comunque al rischio di pacchetti raggiungibili e
deve restare nella revisione SBOM e delle vulnerabilità. Viceversa, la presenza nello SBOM non
dimostra che un prodotto/versione sia certificato. Azure è implementato con ID runtime
canonico `azure`, ma la matrice attuale non dichiara `azure-blob`
supportato nella release.

## Record di evidenze della release

Conserva:

* revisione del codice sorgente, digest immutabili delle immagini, hash SBOM, firme e
  output di verifica;
* database/versioni degli strumenti dello scanner ed eccezioni di vulnerabilità approvate;
* versioni provider/prodotto, protocollo/cipher/issuer TLS dell'endpoint e hash della CA;
* risultati sanitizzati del contratto del provider e dell'integrità SHA-256;
* log di copia/check della migrazione e risultato del rollback;
* punto di consistenza del backup, test di ripristino, RPO/RTO misurati;
* versione OpenShift, revisione SCC, manifest renderizzati, versioni CNI/CSI e
  test di scrittura arbitrary-UID `/tmp`/`/data`.

Non includere mai access key, valori secret, URL pre-firmati, chiavi private, URL
del database, nomi di oggetti del cliente o contenuti degli oggetti nelle evidenze di release o nei bundle
di supporto.

## Risposta di sicurezza

Quando viene divulgata una vulnerabilità di un SDK di storage o di un provider, determina se il
codice e la configurazione interessati sono presenti e raggiungibili, pubblica un advisory
con ambito, aggiorna le immagini/SBOM interessati e riesegui i test di contratto e ripristino.
Il ritiro di un provider è una decisione di ciclo di vita del prodotto con preavviso esplicito,
guida di migrazione e date di supporto. L'attuale guida CaseBender tratta una
distribuzione MinIO legacy solo come sorgente esterna di migrazione/rollback; questa
policy non inventa una data di fine supporto cliente oltre a un piano di
modifica cliente approvato.