Analisi delle vulnerabilità e SBOM
Il CRA trasforma la sua distinta base del software in un obbligo continuo: conoscere ciò che è contenuto nel prodotto, monitorare i relativi componenti alla ricerca di nuove vulnerabilità e correggerle e notificarle entro le scadenze previste dall'articolo 14. Questa pagina illustra il ciclo e lo strumento gratuito che lo gestisce.
Genera un SBOM
Produrre una distinta base del software leggibile da una macchina che copra almeno le dipendenze di primo livello. Si tratta di un requisito vincolante, non di una buona prassi.
Come generarlo ↓Monitorare le vulnerabilità
Confrontare continuamente ogni componente con i dati aggiornati sulle vulnerabilità (NVD, EUVD). I riepiloghi di notifica raggruppati non rispettano la finestra di 24 ore.
Perché i riepiloghi non bastano ↓Valutare, correggere e segnalare
Documentare la sfruttabilità, distribuire una correzione e segnalare le vulnerabilità sfruttate attivamente a ENISA e al CSIRT secondo la tempistica di 24h / 72h / 14 giorni.
Lo strumento che lo fa ↓CRA Vulnerability Analyzer
Caricare il vostro SBOM e l’elenco delle vulnerabilità attive. L’Analyzer confronta ogni componente con il National Vulnerability Database (NVD) e con la banca dati delle vulnerabilità dell’UE (EUVD), segnala i componenti a fine vita (End-of-Life) e genera un rapporto di conformità da allegare alla documentazione tecnica.
Guide pratiche
Genera un SBOM conforme
La distinta base del software (SBOM) è un requisito giuridico vincolante ai sensi dell'allegato I, parte II, punto 1. Questa guida illustra l'ambito e il formato obbligatori, come generarne una e come essa alimenta il ciclo di monitoraggio.
1 · Base giuridica
L'allegato I, parte II ("Requisiti per la gestione delle vulnerabilità"), punto 1, impone ai fabbricanti di "individuare e documentare le vulnerabilità e i componenti … anche redigendo una distinta base del software (SBOM) in un formato comunemente usato e leggibile meccanicamente, riguardante almeno le dipendenze di primo livello del prodotto."
A differenza di alcune disposizioni del CRA che consentono una certa flessibilità interpretativa, l’obbligo di produrre un SBOM leggibile da una macchina che copra almeno le dipendenze di primo livello non ammette approcci alternativi.
2 · Ambito e formato obbligatori
Copertura dei componenti. L'SBOM deve documentare tutte le dipendenze di primo livello, che costituiscono il minimo di legge anziché l'obiettivo raccomandato. Mappare le dipendenze transitive (indirette) ovunque sia possibile; un SBOM superficiale soddisfa la lettera della legge ma è spesso insufficiente per una gestione efficace delle vulnerabilità.
Formato. Il CRA impone un "formato di uso comune e leggibile da macchina". I formati accettati includono:
- SPDX (ISO/IEC 5962:2021): ampiamente adottato, incentrato sulle licenze, adatto alla documentazione di conformità.
- CycloneDX: incentrato sulla sicurezza, particolarmente adatto ai flussi di lavoro di gestione delle vulnerabilità.
- Altri formati strutturati (JSON, XML) prodotti da strumenti riconosciuti sono generalmente accettabili ai fini del requisito di base.
Non archiviare gli SBOM in formato PDF. Il PDF potrebbe essere contestato dalle autorità di vigilanza del mercato in quanto non leggibile meccanicamente. Archiviare l'output nativo in formato JSON, XML o tag-value prodotto dalla catena di strumenti.
Campi di metadati obbligatori
| Campo | Descrizione |
|---|---|
| Nome del componente | Identificativo univoco della libreria, del pacchetto o del modulo |
| Versione | Stringa di versione esatta; gli intervalli di versione non sono sufficienti |
| Fornitore / origine | Nome dell'editore, del fornitore o del progetto open source |
| Relazioni tra le dipendenze | Dirette vs. transitive; grafo delle dipendenze ove possibile |
| Hash crittografico | Controllo di integrità SHA-256 o più robusto per ciascun componente |
| Identificativo della licenza | Espressione di licenza SPDX (ad es. Apache-2.0, MIT) |
3 · Generazione dell'SBOM
La maggior parte delle piattaforme moderne è in grado di generare automaticamente gli SBOM in fase di build senza costi aggiuntivi:
- GitHub / Actions: Dependency Graph → Export SBOM (Settings → Code security). Produce SPDX JSON.
- GitLab: I report CycloneDX vengono generati nativamente dal job CI/CD di scansione delle dipendenze.
- Syft (Anchore): CLI open source che produce SPDX e CycloneDX per immagini di container, filesystem e manifest di pacchetti.
- cdxgen: SBOM in formato CycloneDX per npm, Maven, pip, Go, Rust e altri.
Screening delle vulnerabilità. Prima di finalizzare qualsiasi SBOM, verificare ogni componente rispetto alle banche dati delle vulnerabilità note. Sia lo scanner di GitHub sia Syft si integrano con Grype a tal fine. Includere un componente con una vulnerabilità nota e già corretta costituisce una violazione diretta dell'Allegato I e non ammette alcuna flessibilità interpretativa.
Se esiste una versione corretta di un componente, è necessario utilizzarla. Il CRA non prevede alcuna categoria di "rischio accettato" per le vulnerabilità risolte. Intervenire su ogni riscontro prima di immettere il prodotto sul mercato.
4 · Manutenzione del ciclo di vita e conservazione
Un SBOM è un documento vivo, aggiornato di continuo durante l'intero ciclo di vita supportato del prodotto per riflettere i componenti corretti, le nuove dipendenze, i componenti a fine vita rimossi e le modifiche della catena di approvvigionamento. Tutte le versioni della documentazione tecnica, compresi gli SBOM, devono essere conservate per almeno 10 anni dalla prima immissione sul mercato…
Sezioni 4–9: ciclo di vita, sanzioni, BSI TR-03183-2 e la lista di controllo della preparazione
Il resto della guida tratta l'obbligo di conservazione decennale, la riservatezza e la divulgazione lungo la catena di approvvigionamento, l'integrazione con la segnalazione delle vulnerabilità di cui all'Articolo 14, la frequenza del monitoraggio, le norme più rigorose del BSI tedesco, le sanzioni (fino a 15 milioni di € o al 2,5 % del fatturato) e una lista di controllo della preparazione pronta all'uso.
Strumenti e analisi correlati
Matrice di conformità
Ogni obbligo del ciclo di vita con il relativo riferimento all'articolo; monitora i tuoi progressi e scarica la lista di controllo completa.
Situazione attuale
A che punto è il CRA oggi: atti di esecuzione, norme armonizzate e il percorso verso dicembre 2027.
Calcolatore dei costi
Una stima indicativa di quanto è probabile che costi raggiungere e mantenere la conformità.