Richieste di SBOM dai clienti: come rispondere

Fornisce componenti o software embedded a dei fabbricanti? Veda la guida SBOM per i fornitori, che tratta contratti, VEX e una SBOM per ogni versione software consegnata.

Perché i clienti lo chiedono ora

• Il Cyber Resilience Act. I fabbricanti che vendono nell'UE devono avere una SBOM del proprio prodotto e prestare attenzione ai componenti che integrano, quindi la domanda scende lungo la supply chain.
• NIS2. I soggetti essenziali e importanti devono occuparsi della sicurezza della supply chain. La direttiva non cita le SBOM, ma una SBOM è uno dei modi in cui un acquirente può vedere che cosa distribuisce un fornitore. Veda le SBOM come evidenza per NIS2, ISO 27001 e SOC 2.
• Regole di settore. La sezione 524B della FDA richiede una SBOM per i cyber device, e altri settori hanno regole proprie.
• Il loro lavoro sulle vulnerabilità. Un cliente che sa che cosa contiene il Suo prodotto può capire se una nuova CVE lo riguarda senza aprire un ticket di assistenza.

Che cosa concordare prima di inviare qualsiasi cosa

Domanda	Perché è importante
Quale prodotto e quale versione?	Una SBOM descrive una sola release. Invii quella che il cliente usa, non l'ultima build.
Quale formato?	La maggior parte delle richieste accetta CycloneDX o SPDX. Chieda se serve una versione specifica.
Con quale profondità?	Le dipendenze di primo livello potrebbero non bastare. Si aspetti che Le vengano chieste quelle transitive.
Una volta sola o a ogni release?	Un contratto può prevedere una nuova SBOM per ogni release, il che esclude qualsiasi lavoro manuale.
A quali condizioni?	Una SBOM mostra come è costruito il Suo prodotto. Concordi le condizioni di riservatezza e la modalità di consegna del file.

Che cosa contiene una buona risposta

• Una SBOM nel formato concordato, per l'esatta release usata dal cliente.
• Ogni componente con nome, versione, fornitore, licenza e un identificatore di pacchetto.
• Le relazioni tra le dipendenze, così un pacchetto transitivo può essere ricondotto a ciò che lo ha introdotto.
• La data, lo strumento che l'ha prodotta e la build da cui proviene.
• Una nota onesta su tutto ciò che la SBOM non copre (veda completezza della SBOM).

Per vedere come sono fatti i file, consulti gli esempi di SBOM. Sui due formati, veda CycloneDX vs SPDX. Per sapere che cosa controllerà probabilmente il cliente all'arrivo, veda la checklist di qualità SBOM.

Errori che si pagano in seguito

• Inviare l'ultima build invece di quella distribuita. Le build non sono riproducibili per impostazione predefinita, quindi ricompilare lo stesso commit non garantisce la stessa SBOM. Solo la SBOM della build che ha prodotto la release mostra ciò che il cliente ha ricevuto.
• Assemblarla a mano per l'occasione. Soddisfa la richiesta una volta, e dovrà ripetere il lavoro per il prossimo cliente e la prossima release. Veda l'automazione delle SBOM.
• Promettere più di quanto si possa ripetere. "Ne invieremo una a ogni release" è una frase facile da scrivere in un contratto e difficile da mantenere senza automazione.
• Considerare la SBOM un punto d'arrivo. La domanda successiva è "siete colpiti da questa CVE?", e arriva insieme alla prossima grande vulnerabilità.

Come prepararsi alla prossima richiesta

Le richieste diventano semplici quando la SBOM esiste già. Ne produca una per ogni release nella pipeline che la compila, la conservi con la release e la monitori per individuare nuove vulnerabilità. A quel punto una richiesta si risolve con un download e una breve nota, e Lei può rispondere alla domanda successiva dallo stesso record.

Come se ne occupa CRACI

CRACI registra una SBOM da ogni build GitHub Actions eseguita sui propri runner, così ogni release ne ha già una quando qualcuno la chiede.

• Esportazione in CycloneDX o SPDX, comprese le dipendenze transitive e le vulnerabilità trovate nei componenti.
• Evidenze dalla build stessa. Ogni componente nella SBOM era nella build, e vengono registrate le dipendenze nascoste che sfuggono agli strumenti basati sui lockfile.
• Uno stato di completezza per ogni job, così Lei sa che cosa sta inviando prima di inviarlo.
• Cronologia delle build. Può vedere le build passate e le relative SBOM, e quali build contenevano una dipendenza vulnerabile, entro il Suo periodo di retention.
• Risposte alla domanda successiva. CRACI continua a rivalutare le SBOM monitorate, supporta VEX e mostra quali prodotti eseguono quali versioni nella vista dell'inventario.

Richieste di SBOM dai clienti: domande frequenti

Siamo obbligati a fornire la nostra SBOM ai clienti?

Dipende dal mercato e dai contratti. Il Cyber Resilience Act rende la SBOM parte della documentazione tecnica, che va consegnata su richiesta a un'autorità di vigilanza del mercato, e non ne impone la pubblicazione. Il diritto di un cliente a riceverla deriva di solito dal contratto, quindi verifichi che cosa ha concordato.

Quale formato di SBOM dovremmo inviare?

CycloneDX o SPDX, a seconda di ciò che il cliente chiede. Se non ha preferenze, vanno bene entrambi. Chieda se i suoi strumenti richiedono una versione specifica.

Dobbiamo includere le dipendenze transitive?

Il Cyber Resilience Act chiede almeno le dipendenze di primo livello, ma molti acquirenti si aspettano l'intero albero, e le vulnerabilità si trovano spesso nei pacchetti transitivi. Una SBOM completa è la risposta più sicura.

La SBOM va inviata al cliente sotto NDA?

È una decisione che spetta a Lei e al Suo cliente. Una SBOM mostra di che cosa è fatto il Suo prodotto, quindi molti fornitori la condividono nell'ambito del contratto esistente o di un NDA, invece di pubblicarla.

Con quale frequenza dovremmo inviare una SBOM aggiornata?

Con la frequenza concordata. Le dipendenze cambiano a ogni release, quindi una nuova SBOM per release è la scelta onesta di partenza, e diventa praticabile solo se la SBOM esce dalla build.

E se il cliente chiede di una release più vecchia?

Le serve la SBOM della build che ha prodotto quella release. CRACI conserva la cronologia delle build entro il Suo periodo di retention, 180 giorni per impostazione predefinita con retention personalizzata sul piano Enterprise, quindi esporti ciò che deve conservare più a lungo.

Non abbiamo mai creato una SBOM. Da dove iniziamo?

Inizi dalla release usata dal Suo cliente e da uno strumento che lavori sulla Sua build reale. Se usa GitHub Actions, spostare la build sui runner CRACI Le fornisce una SBOM registrata fin dalla prima esecuzione.