Generazione di SBOM tra i team di sviluppo: una policy, ogni pipeline

Perché gli scanner dei singoli team non fanno un programma SBOM

Punti cinque strumenti sullo stesso prodotto e otterrà cinque SBOM. Le differenze sono strutturali, non bug:

• Input diversi, letti in momenti diversi. Uno strumento legge il lockfile, un altro l'albero delle dipendenze installato, un altro l'immagine container, un altro il binario. Ciascuno vede una porzione diversa del prodotto.
• Nomi diversi per la stessa cosa. Uno identifica i componenti tramite package URL, un altro tramite CPE, un altro solo tramite nome del file. Due SBOM che descrivono la stessa libreria non si possono unire su una chiave comune.
• Profondità diverse. Alcuni elencano solo le dipendenze dirette, alcuni l'intero albero transitivo, e alcuni elencano anche gli strumenti di build. Perché i generatori non concordano sullo stesso repository è mostrato in generatori di SBOM open source.
• Alcuni strumenti rispondono a un'altra domanda. Gli scanner di vulnerabilità dell'infrastruttura riportano ciò che è installato sugli host in esecuzione. È utile per le operations, e non è una descrizione del prodotto che Lei distribuisce.

La conseguenza: non può unire, deduplicare o confrontare le SBOM tra prodotti, e non può mostrare a un auditor un unico processo, perché non ce n'è uno.

Metodo	Input che legge	Quando	Cosa non vede	Identificatore tipico
Scanner di lockfile o manifest	Lockfile e manifest nel checkout	Prima o dopo la build	Tutto ciò che nessun lockfile elenca: hook di installazione, download degli script di build, immagini base	Package URL
Scanner di immagini container	Database dei pacchetti e file nell'immagine	Dopo la build	Strumenti usati solo nella build, codice compilato all'interno, tutto ciò che non ha un record di pacchetto	Package URL per i pacchetti del sistema operativo e dei linguaggi
Scanner di binari o firmware	Stringhe e firme nel binario	Dopo la build	La certezza: versioni e componenti sono dedotti	CPE o nome dedotto
Scanner di vulnerabilità degli host	Software installato sui server in esecuzione	In esercizio	Il prodotto così come viene consegnato ai clienti	CPE o nome del prodotto del vendor
Registrazione durante la build	Ciò che la build di rilascio ha scaricato	Durante la build	Il software che Lei non ha compilato; ciò che non ha potuto vedere viene segnalato come incompleto	Package URL

La policy SBOM: cosa standardizzare

Standardizzi la SBOM, non lo scanner. La policy fissa l'output e il processo; ogni pipeline la rispetta con il miglior generatore che può eseguire. Ogni riga qui sotto è qualcosa che Lei può verificare.

Requisito	La regola	Perché	Come verificarlo
Ambito	Ogni rilascio di prodotto consegnato a un cliente, compresi firmware e immagini container. Strumenti interni facoltativi.	Clienti e regolatori chiedono di ciò che Lei distribuisce.	Ogni rilascio nel registro dei rilasci ha una SBOM.
Formato e versione	Un formato principale, CycloneDX o SPDX, con una versione minima. Accetti l'altro su richiesta.	Un formato significa un parser, un validatore e un archivio. BSI TR-03183-2 richiede CycloneDX 1.6 o successivo oppure SPDX 3.0.1 o successivo, una soglia sensata per i clienti UE.	La validazione dello schema riporta formato e versione.
Campi minimi	Una package URL su ogni componente che ne ha una, un CPE solo dove non esiste, fornitore, versione, licenza dichiarata, relazioni di dipendenza, nome e versione dello strumento, timestamp e contesto di generazione.	Sono i campi usati per il matching, la revisione delle licenze e gli audit. Li allinei agli elementi minimi indicati in che cos'è una SBOM.	Un controllo dei campi nella pipeline conta i valori mancanti.
Quando viene generata	Nella build CI che produce il rilascio, ogni volta. Non al momento dell'audit, non su un portatile.	Una nuova build non è la stessa build; veda SBOM in fase di build.	L'ID di build della SBOM corrisponde all'ID di build del rilascio.
Profondità	L'intero albero transitivo, non solo il primo livello.	Il minimo del CRA sono le dipendenze di primo livello; le vulnerabilità e i clienti vanno più a fondo.	Esistono relazioni di dipendenza sotto il primo livello.
Dove viene archiviata	Insieme all'artefatto di rilascio, recuperabile per prodotto e versione.	Una SBOM che nessuno trova quando arriva un advisory non è un'evidenza.	Recuperi la SBOM di un rilascio a caso per prodotto e versione.
Conservazione	Almeno il periodo di supporto del prodotto più la conservazione della documentazione richiesta dalle Sue normative.	Il CRA fissa un periodo di conservazione per la documentazione tecnica, e la SBOM ne fa parte.	Confronti il periodo della policy con la conservazione di ogni strumento.
Validazione	Ogni SBOM viene validata rispetto allo schema nella pipeline; una non valida fa fallire la build o il gate di rilascio.	Le SBOM non valide falliscono senza avvisi negli strumenti del cliente.	Il log del gate di rilascio mostra un passaggio di validazione.
Responsabilità	Il team di prodotto è responsabile della generazione; la product security è responsabile della policy, delle regole di validazione e del reporting sulla copertura.	La generazione richiede il responsabile della pipeline; la coerenza richiede un unico responsabile delle regole.	Ogni pipeline indica un responsabile.
Eccezioni	Un registro di eccezioni nominative e a tempo: team, motivo, data di fine.	La policy sopravvive ai team che non possono ancora rispettarla.	Nessuna eccezione ha superato la propria data di fine.

La checklist in best practice per le SBOM copre le regole per una singola SBOM; questa policy è il livello sopra di esse. Ogni team dichiara come la propria pipeline rispetta la policy, in un file accanto alla pipeline:

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Generare nella build, non per team a posteriori

La generazione durante la build è lo standard a cui puntare. Descrive la build che è stata distribuita, include le dipendenze nascoste che nessun lockfile elenca, e un unico meccanismo produce SBOM della stessa forma per ogni team su quella pipeline. La differenza si spiega più facilmente con una cucina: uno scanner assaggia la zuppa e indovina la ricetta; una registrazione osserva ciò che entra in cucina.

Uno scanner resta lo strumento giusto per le immagini che Lei non ha compilato, per i binari di terze parti e per i prodotti legacy senza CI. Lo scriva nella policy e registri il contesto di generazione, così chi legge sa che cosa ha visto ogni SBOM.

Situazione	Metodo di generazione	Contesto di generazione da registrare
Rilascio compilato in una CI che Lei controlla	Registri la build, oppure esegua un generatore all'interno del job di rilascio	"Registrato durante la build" oppure "dopo l'installazione, dai file"
Immagine container compilata in CI	Registri la build dell'immagine; scansioni il risultato per i pacchetti del sistema operativo se la registrazione non li copre	ID di build e digest dell'immagine
Immagine o appliance di terze parti	Scanner di immagini, più la SBOM del vendor se esiste	"Output scansionato, non compilato da noi"
Binario di un fornitore	Chieda la SBOM di build del fornitore; analisi del binario come verifica	Fornitore, versione, come è stato ottenuto
Prodotto legacy senza pipeline	Scansioni l'artefatto distribuito; pianifichi una pipeline	"Output scansionato" e un'eccezione con una data di fine

CI miste: GitHub Actions, GitLab e Jenkins in un'unica organizzazione

La policy è indipendente dalla CI per costruzione: definisce l'output, quindi una pipeline GitLab o Jenkins può rispettarla con un passaggio di generazione, e una pipeline GitHub Actions può usare la registrazione durante la build. Regole per un passaggio di generazione:

• Lo esegua nel job di rilascio, dopo il passaggio di installazione, non in un job separato che installa di nuovo.
• Fissi la versione del generatore e fissi le action CI a un commit, non a un tag. Perché questo conta in particolare per gli scanner è spiegato in generatori di SBOM open source.
• Registri il contesto di generazione come "dopo l'installazione, dai file", così chi legge sa che cosa ha visto.
• Validi l'output rispetto allo stesso schema di tutte le altre pipeline.

Generatori open source come Syft, Trivy e cdxgen possono tutti scrivere CycloneDX e SPDX, quindi la regola sul formato non impone la scelta di uno strumento. Per confrontarli, veda strumenti SBOM a confronto.

CRACI oggi supporta GitHub Actions; GitLab CI e Jenkins sono nella roadmap, senza data. La conseguenza per l'adozione: avvii la registrazione durante la build dove si usa GitHub Actions, mantenga i passaggi di generazione altrove e segua entrambi nello stesso report di copertura.

Quando un cliente vuole una specifica versione del formato

Un cliente chiede CycloneDX 1.6 e i Suoi strumenti scrivono 1.7. Succede perché il suo strumento di acquisizione o la sua policy è fissata a una versione; la soglia del BSI è 1.6, quindi i clienti UE la indicano spesso. Le Sue opzioni:

1. Chieda se la versione più recente è accettata. Spesso lo è.
2. Converta con la CycloneDX CLI, poi validi rispetto alla versione di destinazione e verifichi che cosa è andato perso: i campi che esistono solo nella specifica più recente vengono eliminati.
3. Per una richiesta SPDX, la stessa CLI converte da e verso SPDX JSON 2.3. La sua documentazione avverte che la conversione tra SPDX e CycloneDX "può comportare la perdita di alcune informazioni".

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

Il validatore verifica rispetto a CycloneDX 1.7 a meno che Lei non passi --input-version. Regola della policy: conservi la SBOM originale come registro. Una copia convertita è una consegna derivata; archivi la derivazione (strumento, versione, data) insieme a essa. Altro su come rispondere a queste richieste in richieste di SBOM dai clienti, e sui due formati in CycloneDX vs SPDX.

Dati sulle licenze per l'ufficio legale

La stessa SBOM può servire all'ufficio legale, se la policy richiede i campi giusti. L'ufficio legale ha bisogno della licenza di ogni componente, della differenza tra una licenza dichiarata (ciò che dice il pacchetto) e una accertata (ciò che qualcuno ha verificato), degli obblighi copyleft e di un elenco dei componenti senza licenza. CycloneDX 1.6 contrassegna le licenze come dichiarate o accertate, e SPDX ha campi separati per entrambe.

• Richieda identificatori o espressioni di licenza SPDX, come MIT o Apache-2.0 OR MIT.
• Segnali NOASSERTION e le licenze mancanti per la revisione. In SPDX, NOASSERTION significa che non è stata fatta alcuna determinazione o che non è stata fornita alcuna informazione; non è una licenza.
• Inoltri le licenze copyleft all'ufficio legale prima del rilascio, non dopo.

Una SBOM contiene le licenze dichiarate. Una revisione della conformità delle licenze, con licenze accertate, note e obblighi, è lavoro legale o un compito per uno strumento specializzato; veda conformità delle licenze open source.

Adozione team per team

Fase	Responsabile	Criterio di uscita	Ostacolo tipico
1. Inventario: prodotti, pipeline, sistemi CI e generatori attuali, una riga per pipeline di rilascio	Product security	Ogni prodotto distribuito ha una riga	Nessuno sa quale pipeline compila un rilascio
2. Pubblicare la policy con il registro delle eccezioni	Product security	Policy approvata e pubblicata	Dibattito su quale strumento imporre (la policy non ne impone nessuno)
3. Pilota con uno o due team che hanno un motivo: una richiesta di un cliente, una scadenza, un prodotto che lo strumento attuale non riesce a gestire	Team pilota	I rilasci pilota vengono distribuiti con SBOM conformi	I team senza un motivo urgente lo mettono in secondo piano
4. Aggiungere gate di validazione nelle pipeline pilota	Team pilota	Una SBOM non valida fa fallire il rilascio	Timore di bloccare i rilasci; iniziare con un avviso
5. Estendere per sistema CI; dismettere uno scanner di team solo quando il sostituto rispetta la policy	Team di prodotto	Obiettivo di copertura raggiunto per sistema CI	Pipeline senza responsabile
6. Riportare la copertura ogni mese	Product security	Il report arriva al management ogni mese	Metriche calcolate a mano

Il foglio di calcolo dell'inventario della fase 1 dovrebbe essere l'ultimo; come abbandonare i fogli di calcolo è spiegato in automazione delle SBOM. Un prodotto basato su Yocto è un pilota frequente, perché gli scanner generici faticano a gestirlo; veda perché gli scanner SBOM non vedono le build Yocto.

Misurare la copertura

I numeri che chiedono il management e gli auditor, ciascuno definito come rapporto:

• Copertura dei rilasci: rilasci distribuiti con una SBOM conforme alla policy ÷ rilasci distribuiti.
• Copertura dei prodotti: prodotti con almeno una SBOM conforme nel periodo di supporto corrente ÷ prodotti in supporto.
• Tasso di superamento della validazione: SBOM che superano la validazione ÷ SBOM generate.
• Copertura degli identificatori: componenti con una package URL (o un CPE) ÷ componenti.
• Copertura delle licenze: componenti con una licenza dichiarata ÷ componenti.
• Completezza: SBOM il cui generatore dichiara che sono complete ÷ SBOM. Possibile solo dove lo strumento lo riporta.
• Tempo alla SBOM: tempo dal rilascio alla disponibilità della SBOM.

Un esempio di report mensile (dati illustrativi):

Metrica	Pipeline GitHub Actions	Pipeline GitLab e Jenkins	Tutte
Copertura dei rilasci	46 / 48	19 / 27	65 / 75
Tasso di superamento della validazione	100%	92%	97%
Copertura degli identificatori	99%	88%	95%
Eccezioni aperte	1	4	5

Come evidenza per un regolatore o un auditor, l'insieme è composto dalla policy, dal registro delle eccezioni, dal report di copertura e da alcune SBOM di esempio. Mostra un unico processo, applicato e misurato. Per il lato CRA, veda la guida al CRA.

Come si inserisce CRACI

Per le pipeline GitHub Actions, CRACI è il runner: Lei imposta runs-on: craci e ogni job ottiene una SBOM registrata senza passaggio di generazione. Ogni SBOM riporta uno stato di completezza, le dipendenze transitive, una package URL per pacchetto e la licenza dichiarata di ogni componente, e si esporta come CycloneDX o SPDX. Le regole di policy sulle licenze possono bloccare una build, le SBOM monitorate vengono rivalutate di continuo e lo storico delle build mostra quali build contenevano una dipendenza vulnerabile. Questo dà a quei team, per impostazione predefinita, le righe della policy "generata nella build di rilascio", "identificatore" e "licenza". Si possono aggiungere SBOM di terze parti, così i componenti acquistati vengono monitorati insieme alle Sue build.

Veda la generazione di SBOM su CRACI e le SBOM in GitHub Actions.

Quando CRACI non è la risposta

• Team su GitLab CI o Jenkins: non oggi, è nella roadmap. Usi un passaggio di generazione che rispetti la policy.
• GitHub Enterprise Server: oggi non supportato.
• Scansione di infrastruttura e host, cioè ciò che è installato sui server e le configurazioni errate: è un altro lavoro; mantenga quegli strumenti.
• Analisi di binari o firmware di immagini di fornitori che Lei non compila: CRACI registra le build e non scansiona binari.
• Conservazione lunga: CRACI conserva i dati di build per 180 giorni per impostazione predefinita, con conservazione personalizzata su Enterprise. Se la Sua policy richiede le SBOM più a lungo, le esporti nel Suo archivio.

Generazione di SBOM tra i team: domande frequenti

Come standardizziamo la generazione di SBOM tra team che usano strumenti diversi?

Standardizzi l'output, non lo strumento. Scriva un'unica policy che fissi formato e versione, campi minimi, quando la SBOM viene generata, dove viene archiviata, per quanto tempo viene conservata e chi la valida. Lasci che ogni pipeline la rispetti con il miglior generatore che può eseguire e misuri la copertura rispetto alla policy.

Che cosa deve includere una policy SBOM?

Ambito, formato e versione minima, campi minimi (package URL, fornitore, versione, licenza dichiarata, dipendenze, strumento, timestamp, contesto di generazione), generazione nella build di rilascio, profondità transitiva completa, archiviazione con il rilascio, conservazione, validazione nella pipeline, responsabilità e un registro di eccezioni a tempo.

Ogni team deve eseguire il proprio scanner, o le SBOM devono venire dalla build?

Dalla build, dove possibile. Una SBOM in fase di build descrive la build che è stata distribuita e dà a ogni team su quella pipeline SBOM della stessa forma. Mantenga gli scanner per ciò che non ha compilato: immagini di terze parti, binari dei fornitori e prodotti legacy senza pipeline.

Un cliente vuole la nostra SBOM in una versione precedente di CycloneDX. Che cosa facciamo?

Chieda prima se la versione più recente è accettata. Se no, converta una copia con la CycloneDX CLI (cyclonedx convert con --output-version v1_6), la validi rispetto a quella versione e verifichi quali campi sono stati eliminati. Conservi l'originale come registro e archivi come è stata derivata la copia.

Come portiamo all'ufficio legale i dati sulle licenze dalle nostre SBOM?

Richieda nella policy identificatori o espressioni di licenza SPDX, segnali NOASSERTION e le licenze mancanti per la revisione e inoltri le licenze copyleft all'ufficio legale prima del rilascio. La SBOM contiene le licenze dichiarate; licenze accertate, note e obblighi richiedono una revisione delle licenze.

Come misuriamo la copertura SBOM tra i prodotti?

Come rapporti: rilasci distribuiti con una SBOM conforme, prodotti in supporto con una SBOM conforme, tasso di superamento della validazione, componenti con una package URL, componenti con una licenza dichiarata, SBOM complete dove lo strumento lo riporta, e tempo dal rilascio alla SBOM. Li riporti ogni mese per sistema CI.

Quali evidenze servono per dimostrare a un auditor che la generazione di SBOM è coerente?

La policy, il registro delle eccezioni, il report mensile di copertura e alcune SBOM di esempio con il loro contesto di generazione. Insieme mostrano un unico processo, applicato a ogni rilascio e misurato, ed è ciò che un auditor o un cliente verifica.