DevKit DossierChe cosa richiede il regolamento sulla ciberresilienza per l'SBOM
Ultimo aggiornamento: 2026-09-30
Il regolamento sulla ciberresilienza (Cyber Resilience Act, regolamento (UE) 2024/2847) chiede ai fabbricanti di redigere una distinta base del software (SBOM) nell'ambito della gestione delle vulnerabilità. Il testo chiede un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello, e colloca l'SBOM nella documentazione tecnica. Il requisito si applica dall'11 dicembre 2027, insieme agli obblighi principali del regolamento.
Che cosa dice il testo
La definizione, articolo 3, punto 39):
"«distinta base del software»: un registro formale contenente i dettagli e le relazioni della catena di approvvigionamento dei componenti inclusi negli elementi software di un prodotto con elementi digitali;"
Il requisito, allegato I, parte II, punto 1). I fabbricanti di prodotti con elementi digitali:
"identificano e documentano le vulnerabilità e i componenti contenuti nel prodotto con elementi digitali, redigendo anche una distinta base del software in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto;"
Dove si colloca, allegato VII, punto 2, lettera b):
"le informazioni necessarie e specifiche sui processi di gestione delle vulnerabilità messi in atto dal fabbricante, tra cui la distinta base del software, la politica di gestione della divulgazione coordinata delle vulnerabilità, la prova della fornitura di un indirizzo di contatto per la segnalazione delle vulnerabilità e una descrizione delle soluzioni tecniche scelte per la distribuzione sicura degli aggiornamenti;"
Chi può chiederlo, allegato VII, punto 8:
"se del caso, la distinta base del software, a seguito di una richiesta motivata di un’autorità di vigilanza del mercato, a condizione che ciò sia necessario affinché tale autorità possa verificare la conformità ai requisiti essenziali di cibersicurezza di cui all’allegato I."
Il formato, articolo 13, paragrafo 24:
"La Commissione può, mediante atti di esecuzione che tengano conto delle norme e delle migliori pratiche europee o internazionali, specificare il formato e gli elementi della distinta base del software di cui all’allegato I, parte II, punto 1."
La pubblicazione, considerando 77:
"I fabbricanti non dovrebbero essere obbligati a rendere pubblica la distinta base del software."
Che cosa significa in pratica
- Il testo non indica alcun formato. Le sue parole sono "di uso comune e leggibile da un dispositivo automatico"; né CycloneDX né SPDX compaiono nel regolamento. Al 29 settembre 2026 la Commissione non ha adottato alcun atto di esecuzione ai sensi dell'articolo 13, paragrafo 24, sul formato e sugli elementi dell'SBOM.
- Secondo la lettera del testo, la profondità minima è quella delle dipendenze di primo livello. La parola "almeno" fissa una soglia minima, non un tetto.
- L'SBOM fa parte della gestione delle vulnerabilità. L'articolo 13, paragrafo 8, chiede che le vulnerabilità siano gestite all'atto dell'immissione sul mercato del prodotto e per la durata del periodo di assistenza.
- Il testo non chiede espressamente un SBOM per ogni release. A una lettura piana del testo, un registro dei componenti di ogni versione immessa sul mercato è ciò che permette a un fabbricante di dire quali versioni contengono un dato componente.
- L'SBOM fa parte della documentazione tecnica, che l'articolo 13, paragrafo 13, chiede ai fabbricanti di tenere "per un periodo di almeno dieci anni dalla data di immissione sul mercato del prodotto con elementi digitali o per il periodo di assistenza, se quest’ultimo è superiore".
- Pubblicarlo è una scelta del fabbricante. Se il fabbricante decide di mettere l'SBOM a disposizione degli utilizzatori, l'allegato II, punto 9, chiede informazioni sul luogo in cui è possibile accedervi.
- Le autorità possono chiederlo: su richiesta motivata (allegato VII, punto 8) e per una valutazione della dipendenza a livello dell'Unione (articolo 13, paragrafo 25).
Che cosa conservare come prova
- L'SBOM di ogni versione immessa sul mercato, sotto forma del file prodotto dalla vostra build.
- Un hash e l'indicazione di data e ora per ogni file, per mostrare che non è cambiato.
- Il nome e la versione dello strumento che lo ha generato, e il formato.
- Le vulnerabilità trovate in ogni versione, quando ne siete venuti a conoscenza e che cosa è stato fatto. Secondo l'articolo 13, paragrafo 7, i fabbricanti "documentano sistematicamente" gli aspetti pertinenti di cibersicurezza.
- Il luogo in cui è possibile accedere all'SBOM, se lo mettete a disposizione degli utilizzatori.
Il ruolo di DevKit Dossier
DevKit Dossier conserva un archivio SBOM per release. La vostra CI genera un file JSON CycloneDX o SPDX con Syft o Trivy e lo carica; DevKit Dossier non è uno scanner e conserva il file byte per byte, con un hash e la data e ora del caricamento. Ogni giorno confronta l'SBOM attuale di ogni release con OSV e gli avvisi di GitHub, il catalogo KEV della CISA, EPSS e i punteggi NVD; crea inoltre un inventario delle licenze e un fascicolo di prove (un file ZIP con pack.json, pack.pdf, gli SBOM byte per byte e un README.txt) da allegare alla documentazione tecnica dell'allegato VII. Vi aiuta a conservare le vostre prove documentali: non fornisce consulenza legale, non certifica nulla e non invia nulla alla piattaforma unica di segnalazione dell'ENISA. È ospitato nell'UE ed è self-service, a un prezzo fisso per organizzazione di 49, 99 o 249 EUR al mese, con una prova di 14 giorni.
Fonti
Questa guida contiene informazioni generali e non costituisce consulenza legale.