# 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. --- _Basato sul deliverable OCCTET D2.3 – CRA Adoption Best Practice Document (v1.0, marzo 2026), distribuito con licenza CC BY 4.0._