Manutenzione della SBOM tra le release del prodotto
Sytance · Aggiornato
La SBOM deve rimanere collegata alla release software che descrive. Un aggiornamento software può modificare i componenti, mentre una correzione della SBOM può limitarsi a correggere informazioni su una release invariata. Registrare entrambe le versioni consente di determinare cosa hanno ricevuto i clienti e quale inventario lo descriva accuratamente.
Il software descritto da ciascun inventario
Scegliere un punto ripetibile del processo di build o rilascio in cui generare la SBOM. Conservare la revisione del codice sorgente, le dipendenze risolte, la configurazione di build e l’identità dell’artefatto finale necessarie per riprodurre o analizzare l’inventario.
La guida CycloneDX distingue gli inventari generati dal codice sorgente, durante una build e in esercizio. Queste fasi possono contenere software diversi. Indicare la fase comunica al destinatario se la SBOM descrive dipendenze dichiarate, un risultato di build o software distribuito.
Per un gateway, combinare le informazioni della build dell’applicazione, dell’immagine di base e dei componenti firmware forniti. Mantenere il collegamento alla SBOM di ogni fornitore. Un servizio cloud usato dal gateway potrebbe richiedere un inventario separato e una propria cadenza di rilascio.
Modifiche dei componenti tra le release
Il confronto tra release mostra quali componenti siano stati aggiunti, rimossi, aggiornati o ricompilati, nonché i cambiamenti nei percorsi di dipendenza. Il solo conteggio dei componenti può non rilevare una sostituzione: una libreria può essere rimossa e un’altra aggiunta senza modificare il totale.
Usare identità normalizzate per il confronto, conservando versioni e identificativi originali. Se uno strumento inizia a riconoscere pacchetti prima sconosciuti, distinguere una migliore visibilità da una modifica effettiva del software.
- Componenti aggiunti o rimossi e relativi percorsi di dipendenza a monte.
- Modifiche di versione, patch a valle e hash degli artefatti cambiati.
- Modifiche alle dichiarazioni di licenza o ai produttori dei componenti.
- Nuove lacune, identificativi corretti e revisioni della SBOM dei fornitori.
Verifiche prima del rilascio
Convalidare il file rispetto alla versione del formato, quindi esaminarne il significato. Confermare che ogni riferimento sia risolvibile, che il prodotto radice corrisponda alla release prevista e che il destinatario possa accedere alle SBOM dei componenti collegate.
Eseguire controlli su vulnerabilità e licenze della release candidata e registrare i risultati per quella release. Un nuovo problema ad alta priorità richiede una decisione sul trattamento. Riesaminare una vecchia eccezione se è cambiata la versione del componente o sono mutate le ipotesi operative.
Archiviare insieme l’artefatto accettato, la SBOM, i riferimenti di build e l’esito della revisione. Se si usano firme, verificarle e confermare che appartengano all’emittente atteso.
Correzioni a una SBOM esistente
La guida congiunta SBOM del 2026 richiede una SBOM per ogni versione software o aggiornamento e una SBOM revisionata quando si correggono errori o diventano noti nuovi dettagli sui componenti. Distingue inoltre le informazioni sconosciute da quelle deliberatamente omesse.
Ad esempio, un fornitore corregge il produttore di un componente mentre i byte del firmware restano invariati. Mantenere l’identità del firmware, emettere una nuova revisione della SBOM, spiegare la correzione e conservare il documento precedente. I destinatari potranno così distinguere una correzione dei dati da un aggiornamento software.
Pubblicare l’aggiornamento tramite il canale di distribuzione concordato. Una pagina di destinazione stabile può indicare la revisione corrente, mentre file immutabili ne conservano la cronologia. Confermare che i destinatari possano identificare la revisione che sostituisce quella precedente.
Nuove vulnerabilità nelle release supportate
Quando arriva un avviso, cercare le identità dei componenti in tutte le release supportate. Esaminare le build effettive e l’uso del prodotto prima di determinarne l’impatto. Tenere l’inventario dei componenti separato dalla valutazione delle vulnerabilità, così che la stessa SBOM possa essere rivalutata quando emergono nuove informazioni.
Se la release 1.0 del gateway contiene una libreria interessata e la release 1.1 la rimuove, la nuova release non modifica la composizione dei dispositivi 1.0 già installati. Il team deve comunque gestire quei dispositivi e mantenere un record accurato delle versioni coperte da un avviso o da una dichiarazione VEX.
Concordare chi mantiene gli aggiornamenti dei fornitori, chi valuta l’impatto, chi approva la risposta e chi la comunica. Definire i tempi di revisione in base agli obblighi di supporto del prodotto e alla gravità delle nuove informazioni, anziché affidarsi solo al successivo rilascio pianificato.
Conservazione dei record e passaggio di consegne
Al termine del supporto, conservare la corrispondenza tra release e SBOM e le decisioni necessarie a spiegare le consegne storiche. Limitare i record sensibili quando opportuno, consentendo comunque ai destinatari autorizzati di ottenere le informazioni promesse.
Al passaggio di consegne, il nuovo responsabile della manutenzione deve poter trovare l’inventario di una versione del prodotto, individuare un componente e leggere la valutazione d’impatto più recente. Esaminare una release supportata aiuta a individuare record o autorizzazioni di accesso mancanti.