# Checklist SBOM per le PMI (A1.6) Cosa registrare in una distinta base del software (SBOM) e quando. Una SBOM favorisce trasparenza e tracciabilità per i prodotti che utilizzano componenti FOSS, e le pratiche SBOM possono essere adottate in modo progressivo. ## Cosa registrare — Minimo - [ ] Nome del prodotto + versione (identificativo del rilascio) - [ ] Nome del componente + versione - [ ] Dipendenze dirette e transitive (se disponibili) - [ ] Informazioni sulla licenza (ove possibile) - [ ] Identificativi univoci (se disponibili, ad esempio package URL / hash) ## Quando generare o aggiornare la SBOM Minimo: - [ ] Per i rilasci principali (ad esempio versione 1.0, 1.1, 2.0) Consigliato: - [ ] Per ogni rilascio che modifica le dipendenze Aggiornare sempre quando: - [ ] Una patch di sicurezza richiede l'aggiornamento di una dipendenza - [ ] Un componente critico / ad alta esposizione cambia versione - [ ] Viene attuata la correzione di una vulnerabilità ## Livelli di maturità della SBOM ### Livello 1 — Di base - Elenco strutturato delle dipendenze - Aggiornamento ai rilasci principali - Collegata alla documentazione di rilascio ### Livello 2 — Strutturato - Generazione automatizzata della SBOM (ove possibile) - Dipendenze dirette + transitive - Registrazione delle licenze - SBOM archiviata insieme agli artefatti di rilascio ### Livello 3 — Avanzato - Generazione della SBOM integrata nella CI/CD - Monitoraggio continuo delle dipendenze - Verifica degli hash - Tracciamento storico delle versioni della SBOM - Analisi d'impatto rapida per le CVE --- _Basato sul deliverable OCCTET D2.3 – CRA Adoption Best Practice Document (v1.0, marzo 2026), distribuito con licenza CC BY 4.0._