Generatore di SBOM: la distinta base del software CycloneDX per il regolamento sulla ciberresilienza

Allegato I, parte II, punto 1, del regolamento (UE) 2024/2847: i fabbricanti «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». Si applica dall'11 dicembre 2027 (articolo 71).

• La distinta base fa parte della documentazione tecnica, con i processi di gestione delle vulnerabilità (allegato VII, punto 2, lettera b)).
• La si fornisce a un'autorità di vigilanza del mercato su richiesta motivata (allegato VII, punto 8). Non è obbligatorio renderla pubblica (considerando 77).
• Se sceglie di metterla a disposizione degli utilizzatori, le informazioni per l'utilizzatore indicano dove (allegato II, punto 9).
• La Commissione può specificarne il formato e gli elementi con un atto di esecuzione (articolo 13, paragrafo 24). CycloneDX e SPDX sono formati di uso comune.

Un file JSON CycloneDX 1.6 con il prodotto come componente principale, ogni pacchetto con la versione esatta e l'URL del pacchetto (purl), e le dipendenze di primo livello del prodotto quando il file di lock le indica. Legge:

• npm package-lock.json (lockfileVersion 2 o 3), Yarn yarn.lock (Yarn 1, 2 e successivi) e pnpm-lock.yaml (lockfileVersion 9.0); i pacchetti solo per lo sviluppo sono esclusi quando il file li indica;
• Python requirements.txt con ogni pacchetto bloccato (name==version), come lo scrivono pip freeze o pip-compile;
• Rust Cargo.lock, versione 3 o 4, e Go go.mod, con i moduli indiretti;
• l'albero delle dipendenze Maven scritto da mvn dependency:tree -DoutputFile, e Gradle gradle.lockfile; i pacchetti con scope test sono esclusi;
• PHP Composer composer.lock, senza packages-dev, e NuGet packages.lock.json.

Un file che non segue il suo formato non viene letto: la pagina indica la riga e il motivo invece di tirare a indovinare. Un pacchetto da una fonte diversa dal registro pubblico è elencato senza URL del pacchetto, così il file non indica mai un pacchetto che non ha usato.

Ha già una SBOM prodotta con un altro strumento? La apra come file JSON CycloneDX, o come file JSON SPDX come quello che esporta il grafo delle dipendenze di GitHub (Export SBOM), per verificarne i componenti su OSV.dev e nel catalogo KEV. Viene letta solo per la verifica: per produrre una nuova SBOM, apra i file di lock. Dove nessun file di lock fissa la versione, il file di GitHub indica un intervallo come ^4.17.0: quei componenti sono elencati come non verificati; apra il file di lock per verificarli.

La verifica segnala ogni vulnerabilità trovata su OSV.dev il cui numero CVE è nel catalogo delle vulnerabilità sfruttate note (KEV) dell'Agenzia statunitense per la cibersicurezza e la sicurezza delle infrastrutture (CISA), con la data in cui la CISA l'ha inserita. La CISA inserisce una vulnerabilità quando ci sono prove affidabili che sia stata sfruttata. Dall'11 settembre 2026, l'articolo 14 del regolamento sulla ciberresilienza chiede di notificare una vulnerabilità attivamente sfruttata presente nel prodotto (articolo 3, punto 42) entro 24 ore dal momento in cui se ne viene a conoscenza. Una voce del KEV non lo decide per il Suo prodotto, ma indica dove guardare per prima cosa; la pagina dei termini di notifica conta le ore.

La distinta base elenca ciò che elencano i file di lock. Il codice copiato nel prodotto, i pacchetti del sistema operativo, il firmware e le librerie in altri linguaggi non vi compaiono: li aggiunga Lei. La verifica delle vulnerabilità usa OSV.dev, che riporta solo vulnerabilità pubblicate; non sostituisce la valutazione delle vulnerabilità richiesta dall'allegato I, parte II.

Per il resto della documentazione CRA, il kit documentale CRA redige la documentazione tecnica e la dichiarazione UE di conformità. La pagina sul regolamento sulla ciberresilienza indica la classe del prodotto.