# Checklist e modelli Il toolkit pratico di implementazione per le PMI: checklist e modelli leggeri da spuntare online, stampare o scaricare negli strumenti che usi già. --- ## Checklist di conformità minima essenziale (MVC) (A1.1) Una base di pratiche, in una sola pagina, che la maggior parte delle PMI può adottare per sostenere un'integrazione dei componenti open source allineata al CRA. Pensata per chi ha tempo e risorse limitati, va rafforzata in modo proporzionato in base al rischio. ### A. Ruoli e responsabilità — Chi fa cosa? Assegnare un responsabile per: - [ ] Selezione e approvazione delle dipendenze - [ ] Monitoraggio delle vulnerabilità - [ ] Aggiornamenti di sicurezza / patching - [ ] Documentazione dei rilasci (cosa è cambiato, cosa è stato aggiornato) > Un'attribuzione chiara delle responsabilità evita che i compiti di sicurezza restino impliciti o non assegnati. ### B. Visibilità dei componenti — Sapere che cosa si usa - [ ] Mantenere un semplice registro dei componenti FOSS che includa: - Nome del componente + versione - Dove è utilizzato (modulo / area del prodotto) - Criticità (bassa / media / alta) - Esposizione (interna / limitata / pubblica) - Responsabile degli aggiornamenti - [ ] Generare una SBOM (almeno per i rilasci principali) o mantenere un elenco equivalente delle dipendenze > La visibilità è il fondamento della gestione basata sul rischio. ### C. Due diligence di base — Prima dell'integrazione Per ogni componente importante, verificare che: - [ ] Sia mantenuto attivamente (attività recente / segnali di rilascio) - [ ] Le vulnerabilità note siano state esaminate - [ ] La compatibilità della licenza sia stata verificata - [ ] Esista un contatto di sicurezza o un canale di divulgazione (se applicabile) ### D. Gestione delle vulnerabilità — Cosa fare quando emerge un problema Disporre di un processo interno di base che risponda a queste domande: - [ ] Come riceviamo le notifiche sulle vulnerabilità? - [ ] Chi effettua il triage? - [ ] Come decidiamo l'urgenza? - [ ] Come applichiamo le patch e rilasciamo? - [ ] Come comunichiamo le modifiche (note di rilascio)? ### E. Aggiornamenti e ciclo di vita — Mantenere la sicurezza nel tempo Definire una semplice policy di aggiornamento: - [ ] Con quale frequenza esaminiamo gli aggiornamenti? (ad esempio ogni mese + patch urgenti il prima possibile) - [ ] Come gestiamo i componenti a fine vita? - [ ] Chi approva gli aggiornamenti delle dipendenze? Tenere traccia almeno di: - [ ] Data dell'ultima revisione delle dipendenze - [ ] Data dell'ultimo aggiornamento di sicurezza / rilascio di patch ### F. Evidenze — Poter dimostrare ciò che si è fatto Conservare evidenze leggere da mostrare in caso di necessità: - [ ] Registro dei componenti + SBOM - [ ] Policy di aggiornamento (basta 1 pagina) - [ ] Note sulla gestione delle vulnerabilità (processo + almeno un esempio di voce di registro) - [ ] Note di rilascio che menzionano gli aggiornamenti delle dipendenze / di sicurezza > **Principio MVC** — Inizia in piccolo, sii coerente e adatta i controlli in base al rischio. --- ## Checklist rapida di due diligence (§5.4.5) Dodici domande da porsi prima di integrare un componente FOSS. Non sostituisce una valutazione strutturata del rischio, ma offre un punto di partenza accessibile e proporzionato per le PMI con risorse limitate. ### Visibilità di base - [ ] Il progetto è mantenuto attivamente? - [ ] La cronologia delle versioni è trasparente? - [ ] È disponibile pubblicamente un contatto di sicurezza? ### Consapevolezza delle vulnerabilità - [ ] Le vulnerabilità sono documentate? - [ ] Le correzioni vengono rilasciate in modo strutturato? - [ ] Ci sono prove di reattività? ### Trasparenza della catena di approvvigionamento - [ ] Il componente è incluso nella SBOM? - [ ] Le dipendenze sono visibili? - [ ] Il versionamento è coerente? ### Aspetti legati al ciclo di vita - [ ] Ci sono prove di una manutenzione continua? - [ ] Gli aggiornamenti vengono comunicati chiaramente? - [ ] Lo stato di fine vita è definito? --- ## Registro dei componenti FOSS (A1.2) Un semplice registro dei componenti open source integrati nel tuo prodotto. Supporta tracciabilità, due diligence e monitoraggio lungo il ciclo di vita e può essere gestito in un foglio di calcolo, in SharePoint, in Git o in qualsiasi strumento interno. | Nome del componente | Versione | Utilizzato in | Criticità | Esposizione | Licenza | Attività dei maintainer | Ultima revisione delle vulnerabilità | Responsabile degli aggiornamenti | Note | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | ExampleAuthLib | 2.4.1 | Modulo di autenticazione | Alta | Pubblica | MIT | Attiva (rilasci mensili) | 12 feb 2026 | CTO | Sensibile per la sicurezza. CVE-2025-XXXX corretta nella v2.4.1. Monitoraggio continuo attivo. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - **Criticità:** Bassa / Media / Alta - **Esposizione:** Interna / Limitata / Pubblica --- ## Scheda del componente open source (A1.3) Per i componenti a criticità media o alta, o per qualsiasi componente esposto pubblicamente. Integra il registro dei componenti documentando perché il componente è stato scelto e quale monitoraggio è previsto. ### Componente - **Nome del componente**: - **Versione / intervallo di versioni utilizzato**: - **Repository / link di riferimento** (facoltativo): - **Utilizzato in** (modulo / funzionalità): - **Criticità funzionale** (Bassa / Media / Alta): - **Esposizione** (Interna / Limitata / Pubblica): - **Licenza**: ### Motivazione della scelta — Perché questo componente? - **Perché è stato scelto?** (ad esempio adeguatezza funzionale, stabilità, prestazioni, ecosistema) - **Alternative prese in considerazione** (se presenti): ### Due diligence di base effettuata - [ ] Attività dei maintainer esaminata - [ ] Cronologia delle vulnerabilità esaminata - [ ] Contatto di sicurezza / modalità di divulgazione disponibile (se applicabile) - [ ] Compatibilità della licenza confermata - [ ] Incluso nella SBOM ### Rischi noti / note - **Limitazioni note / punti di attenzione**: - **Punti di attenzione sulla profondità delle dipendenze** (se pertinente): ### Monitoraggio e responsabilità - **Responsabile degli aggiornamenti / persona di riferimento**: - **Fonti di monitoraggio delle vulnerabilità** (ad esempio avvisi di sicurezza, feed CVE, notifiche del repository): - **Frequenza di revisione** (ad esempio ogni mese + notifiche urgenti all'occorrenza): - **Data dell'ultima revisione**: - **Data della prossima revisione prevista**: --- ## Mini-playbook per la gestione delle vulnerabilità (A1.4) Un flusso di gestione delle vulnerabilità strutturato ma leggero, a misura di PMI, dalla prima notifica alla chiusura. ### 1. Presa in carico — Come riceviamo le notifiche Fonti monitorate: - [ ] Avvisi di sicurezza dei progetti - [ ] Database CVE - [ ] Strumento di scansione delle dipendenze - [ ] Segnalazioni dei clienti - [ ] Test interni - **Responsabile delle notifiche**: - **Contatto di riserva**: ### 2. Triage — Stabilire gravità e urgenza Per ogni vulnerabilità, registrare: - **Componente e versione/i interessati**: - **È utilizzato nel nostro prodotto?** (Sì / No) - **Contesto di esposizione** (Interna / Limitata / Pubblica): - **Criticità funzionale** (Bassa / Media / Alta): - **Indicatori di sfruttabilità** (se noti): - **Priorità di risposta proposta** (Bassa / Media / Alta): Regola decisionale (semplice): - Criticità alta + esposizione pubblica → trattare come urgente - Rischio medio → correzione pianificata - Rischio basso → monitorare e correggere nel prossimo ciclo pianificato ### 3. Correzione — Correggere e verificare Azione intrapresa: - [ ] Aggiornamento alla versione corretta - [ ] Applicazione della patch - [ ] Mitigazione / modifica della configurazione - [ ] Soluzione temporanea - **Responsabile**: - **Data obiettivo**: - **Verifica effettuata** (ad esempio test / regressione / verifica del deployment): ### 4. Rilascio e comunicazione - **Note di rilascio aggiornate** (Sì / No): - **SBOM aggiornata** (Sì / No): - **Comunicazione ai clienti / interna necessaria?** (Sì / No) - **In caso affermativo: canale e responsabile del messaggio**: ### 5. Chiusura e lezioni apprese - **Data di chiusura**: - **Cosa ha funzionato / cosa migliorare la prossima volta** (1–2 punti): --- ## Policy di aggiornamento delle dipendenze (A1.5) Una policy sintetica che definisce come le dipendenze di terze parti vengono esaminate, aggiornate e dismesse. Basta una pagina. ### Ambito Si applica alle dipendenze di terze parti, compresi i componenti FOSS. ### Principio Le dipendenze sono gestite secondo un approccio basato sul rischio e orientato al ciclo di vita. Gli interventi di aggiornamento sono proporzionati a criticità, esposizione e impatto. ### Frequenza degli aggiornamenti - **Revisione periodica delle dipendenze** (ad esempio mensile / trimestrale): Gli aggiornamenti di sicurezza vengono applicati in base alla classificazione del rischio: - **Rischio alto:** il prima possibile - **Rischio medio:** correzione pianificata entro il prossimo ciclo di rilascio - **Rischio basso:** monitorato e risolto durante la normale manutenzione ### Responsabilità delle decisioni - **Responsabile dell'approvazione degli aggiornamenti delle dipendenze**: - **Responsabile dell'approvazione delle correzioni di sicurezza urgenti**: ### Dipendenze a fine vita Se una dipendenza non è più supportata o arriva a fine vita, provvediamo a: - Registrare il rischio - Valutare le alternative - Pianificare la migrazione o controlli compensativi - Documentare la decisione e le tempistiche --- ## 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._