Skip to main content
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:
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.