Vai al contenuto principale

Buone pratiche per l'adozione del CRA

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à.

In questa pagina

Toolkit pratico di implementazione per le PMI

Modelli riutilizzabili e indicazioni pratiche per aiutare le PMI ad adottare un approccio proporzionato e orientato al ciclo di vita all’integrazione di componenti FOSS ai sensi del CRA. Gli strumenti sono volutamente leggeri e si adattano alla criticità del prodotto, all’esposizione e alle risorse disponibili.

Spunta le checklist online (i tuoi progressi restano in questo browser), stampale oppure scarica i modelli nello strumento che usi già: un foglio di calcolo, un wiki o un repository Git.

Scarica tutti i modelli (.md)

A1.1 Checklist

Checklist di conformità minima essenziale (MVC)

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.

Scarica .md

A. Ruoli e responsabilità Chi fa cosa?

  • Assegnare un responsabile per:

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

    • Nome del componente + versione
    • Dove è utilizzato (modulo / area del prodotto)
    • Criticità (bassa / media / alta)
    • Esposizione (interna / limitata / pubblica)
    • Responsabile degli aggiornamenti

La visibilità è il fondamento della gestione basata sul rischio.

C. Due diligence di base Prima dell'integrazione

  • Per ogni componente importante, verificare che:

D. Gestione delle vulnerabilità Cosa fare quando emerge un problema

  • Disporre di un processo interno di base che risponda a queste domande:

E. Aggiornamenti e ciclo di vita Mantenere la sicurezza nel tempo

  • Definire una semplice policy di aggiornamento:
  • Tenere traccia almeno di:

F. Evidenze Poter dimostrare ciò che si è fatto

  • Conservare evidenze leggere da mostrare in caso di necessità:

Principio MVC

Inizia in piccolo, sii coerente e adatta i controlli in base al rischio.

§5.4.5 Checklist

Checklist rapida di due diligence

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.

Scarica .md

Visibilità di base

Consapevolezza delle vulnerabilità

Trasparenza della catena di approvvigionamento

Aspetti legati al ciclo di vita

Il componente gestisce funzioni sensibili o è esposto a Internet? Usa la matrice decisionale per individuare il livello di due diligence necessario.

Apri la matrice decisionale

A1.2 Modello

Registro dei componenti FOSS

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.

Scarica .csv Scarica .md

Esempio (riga compilata)

Nome del componenteVersioneUtilizzato inCriticitàEsposizioneLicenzaAttività dei maintainerUltima revisione delle vulnerabilitàResponsabile degli aggiornamentiNote
ExampleAuthLib2.4.1Modulo di autenticazioneAltaPubblicaMITAttiva (rilasci mensili)12 feb 2026CTOSensibile per la sicurezza. CVE-2025-XXXX corretta nella v2.4.1. Monitoraggio continuo attivo.
  • Criticità: Bassa / Media / Alta
  • Esposizione: Interna / Limitata / Pubblica

A1.3 Modello

Scheda del componente open source

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.

Scarica .md

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

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

A1.4 Playbook

Mini-playbook per la gestione delle vulnerabilità

Un flusso di gestione delle vulnerabilità strutturato ma leggero, a misura di PMI, dalla prima notifica alla chiusura.

Scarica .md

Presa in carico Come riceviamo le notifiche

  • Fonti monitorate:
  • Responsabile delle notifiche
  • Contatto di riserva

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

Correzione Correggere e verificare

  • Azione intrapresa:
  • Responsabile
  • Data obiettivo
  • Verifica effettuata ad esempio test / regressione / verifica del deployment

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

Chiusura e lezioni apprese

  • Data di chiusura
  • Cosa ha funzionato / cosa migliorare la prossima volta 1–2 punti

A1.5 Policy

Policy di aggiornamento delle dipendenze

Una policy sintetica che definisce come le dipendenze di terze parti vengono esaminate, aggiornate e dismesse. Basta una pagina.

Scarica .md

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

A1.6 Checklist

Checklist SBOM per le PMI

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.

Scarica .md

Cosa registrare Minimo

Quando generare o aggiornare la SBOM

  • Minimo:
  • Consigliato:
  • Aggiornare sempre quando:

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

La toolchain OCCTET analizza il codice sorgente e genera automaticamente le SBOM, aiutandoti a passare dal livello 1 al livello 3.

Scopri la toolchain OCCTET

Torna su