Una checklist SBOM del CRA equivale a una pagina delle licenze?

I team di prodotto dovrebbero considerare il periodo 2026-2027 come la finestra per costruire l'inventario dei componenti, la generazione di SBOM, i processi di gestione delle vulnerabilità e, separatamente, i flussi di divulgazione delle licenze. Aspettare la valutazione di conformità per scoprire di non avere un registro delle licenze di terze parti rivisto crea una doppia emergenza.

Le tempistiche variano in base alla classe di prodotto e agli atti di attuazione, e la documentazione deve restare aggiornata per tutto il periodo di supporto. Conferma tutte le date con un legale; questa pagina non è consulenza legale.

L'ambito dipende dalla classificazione del prodotto, non dalla dimensione dell'azienda: i prodotti con elementi digitali immessi sul mercato dell'UE rientrano nell'ambito, mentre i prodotti già coperti da norme UE specifiche di settore (dispositivi medici, veicoli a motore, aviazione civile) e i servizi cloud puri senza una componente di prodotto sono generalmente esclusi. Software installabile, firmware, dispositivi connessi e molti modelli di distribuzione open source commerciale possono rientrare nell'ambito quando venduti nell'UE.

Le esclusioni per il SaaS puro esistono nella comprensione comune del mercato, ma richiedono una revisione legale specifica per prodotto.

Il CRA richiede uno SBOM ma questo non copre la divulgazione delle licenze. L'Allegato I, Parte II obbliga i produttori a identificare e documentare i componenti, incluso uno SBOM in un formato comunemente usato e leggibile dalle macchine che copra almeno le dipendenze di primo livello, il che è un dato di identità dei componenti, non testo di licenza rivisto.

Quell'obbligo accelera l'adozione degli SBOM tra i fornitori che vendono nell'UE. I team producono CycloneDX o SPDX dalla CI, spesso per la prima volta, e consegnano i file alla sicurezza o alla conformità. Lo SBOM soddisfa la documentazione dei componenti richiesta dal CRA. Non produce automaticamente avviso, attribuzione o testo completo della licenza per ogni componente.

La documentazione di cybersicurezza del CRA copre la valutazione del rischio, le vulnerabilità, gli aggiornamenti e lo sviluppo sicuro. La sicurezza di prodotto, il PSIRT e il legale sono responsabili di questo lavoro. La conformità delle licenze copre gli obblighi di proprietà intellettuale nel software di terze parti: avviso, attribuzione, condizioni di copyleft. Un flusso di lavoro diverso con barriere di revisione umana.

Confonderli crea falsa sicurezza. Un team può superare una revisione interna di prontezza al CRA con SBOM e SLA di patch, pur fallendo comunque la richiesta di conformità delle licenze di un acquirente perché nessuno ha rivisto il testo delle licenze.

• SBOM del CRA: identità dei componenti per la documentazione di sicurezza e normativa.
• Divulgazione delle licenze: testo completo e attribuzione per legale e acquisti.
• CRA: segnalazione delle vulnerabilità alle autorità in condizioni definite.
• Licenza: condizioni di copyright e distribuzione nelle licenze OSS.
• Stesso input di lockfile, output diversi e responsabili diversi.

Il CRA si aspetta che la documentazione venga aggiornata durante il periodo di supporto quando vulnerabilità e componenti cambiano. La stessa deriva delle dipendenze compromette le dichiarazioni sulle licenze se nessuno rivede cosa è stato rilasciato.

I team con più persone fanno il merge di aggiornamenti ai pacchetti continuamente. Senza reimportazione e ripubblicazione a ogni release, sia il tuo SBOM per il CRA sia la tua divulgazione delle licenze descrivono il prodotto di ieri. La documentazione normativa e i registri rivolti agli acquirenti devono muoversi insieme alla codebase.

I grandi clienti mappano la postura CRA dei fornitori nei loro programmi di supply chain, e continuano comunque a incollare sezioni sulle licenze da modelli di RFP scritti prima che il CRA esistesse. Chiedono SBOM più pagina delle licenze open source più attestazione che l'elenco sia mantenuto.

Gli acquisti formati sul CRA si aspetteranno un accesso duraturo agli artefatti di conformità. Questo non sostituisce il contenuto della divulgazione delle licenze. Alza l'asticella su quanto devono essere aggiornati e accessibili i tuoi registri.

Organizzazione di sicurezza: generazione SBOM, gestione delle vulnerabilità, segnalazione degli incidenti, input per la conformità al CRA, distribuzione sicura degli aggiornamenti.

Conformità / legale / operazioni di ingegneria: inventario delle licenze di terze parti, revisione, barriere di pubblicazione, esportazioni di divulgazione, risposte ai questionari degli acquirenti.

Input condiviso: lockfile e SBOM dalla CI. Output divergente: la sicurezza usa lo SBOM per i CVE; la conformità usa la stessa importazione per i registri delle licenze rivisti.