SBOM e registri dei componenti CRA

Requisito dell’allegato I

individuare e documentare le vulnerabilità e i componenti contenuti nei prodotti con elementi digitali, anche redigendo una distinta base del software in un formato comunemente utilizzato e leggibile dalla macchina, che copra almeno le dipendenze di primo livello dei prodotti;

Regolamento (UE) 2024/2847, allegato I, parte II, punto 1

La SBOM fa parte di un registro dei componenti più ampio. Aiuta il fabbricante a capire quali componenti sono contenuti nel prodotto e quali vulnerabilità possono interessarli.

Che cosa distinguere

Esempio: un registro dei componenti tracciabile

Il seguente registro fittizio descrive una dipendenza software diretta in una release del firmware di un controllore. Illustra informazioni ingegneristiche utili; i campi non costituiscono uno schema aggiuntivo imposto dal CRA.

• Prodotto: firmware del controllore 1.2.0, build di rilascio 120; inventario creato a partire dalla build rilasciata e dai relativi dati sulle dipendenze.
• Componente: example-parser 2.4.0, fornito dal progetto fittizio Example Components; dipendenza diretta del firmware.
• Identità e origine: identificatore del pacchetto, revisione esatta del codice sorgente o riferimento del fornitore e digest effettivo dell’artefatto fornito.
• Uso: il componente analizza un file di configurazione caricato tramite un’interfaccia di manutenzione autenticata. Registrare le opzioni di build pertinenti e il componente chiamante.
• Evidenze: collegare la SBOM leggibile dalla macchina e i record di build o del fornitore utilizzati per verificare questa voce. Conservare l’inventario della release precedente quando cambia il componente.

Il nome e la versione di un componente possono aiutare a trovare potenziali vulnerabilità. Per stabilire se interessano il prodotto serve un’ulteriore analisi: se il codice vulnerabile è incluso, se la funzione interessata viene eseguita, quale input può raggiungere un aggressore e quali controlli sono pertinenti. Una corrispondenza non risolta resta in fase di indagine; non dimostra che il prodotto non sia interessato.

Una dichiarazione come «non interessato» dovrebbe indicare la versione del prodotto, la vulnerabilità, la motivazione tecnica e le evidenze di supporto. Riesaminarla quando cambiano un’opzione di build, la versione del componente, l’interfaccia o un’ipotesi di distribuzione.

Collegamento alla documentazione tecnica

L’allegato VII include nella documentazione tecnica le informazioni sui componenti e sulla SBOM. Richiede inoltre informazioni sul processo di gestione delle vulnerabilità, sulla politica coordinata di divulgazione delle vulnerabilità, sul contatto per le segnalazioni e sulla distribuzione sicura degli aggiornamenti.

Il processo è illustrato in Registri della gestione delle vulnerabilità e prEN 40000-1-3 Gestione delle vulnerabilità.

Stato del formato

L’allegato I richiede una SBOM comunemente utilizzata e leggibile dalla macchina che copra almeno le dipendenze di primo livello. L’articolo 13(24) consente inoltre alla Commissione di specificarne il formato e gli elementi mediante atto di esecuzione, tenendo conto delle norme europee o internazionali e delle migliori pratiche. Le scelte di formato devono quindi distinguere i requisiti di base del regolamento da eventuali requisiti di esecuzione applicabili.

• Un elenco di componenti in PDF non soddisfa il requisito di formato leggibile dalla macchina previsto per una SBOM.
• La SBOM identifica i componenti; la gestione delle vulnerabilità richiede anche analisi dell’impatto, rimedio e comunicazione.
• L’allegato VII prevede l’accesso alla SBOM su richiesta dell’autorità; non stabilisce un obbligo generale di pubblicarla.