Vai al contenuto principale

Buone pratiche per l'adozione del CRA

Linee guida di conformità al CRA per le PMI

Un percorso pratico e proporzionato per le PMI che integrano componenti FOSS: chi deve occuparsi di cosa, come valutare il rischio, quale livello di due diligence applicare e come mantenerla nel tempo.

In questa pagina

Profili tipo nelle PMI: su cosa concentrarsi

Le PMI affrontano l’adozione del CRA partendo da ruoli e livelli di maturità tecnica diversi. I profili che seguono illustrano responsabilità comuni e indicano a cosa ciascun ruolo dovrebbe dare priorità nell’utilizzo e nell’integrazione di componenti FOSS.

Profilo A

Manager non tecnico

CEO / COO / Responsabile operativo

Obiettivo: fare in modo che l’azienda possa dimostrare un approccio alla conformità ragionevole e ripetibile, senza dover entrare nei dettagli tecnici.

  • Assicurarsi che i ruoli siano assegnati (chi gestisce gli aggiornamenti, chi monitora le vulnerabilità, chi approva le dipendenze).
  • Assicurarsi che esistano evidenze di base (disponibilità della SBOM, contatto di sicurezza, policy di aggiornamento, canale di segnalazione delle vulnerabilità).
  • Approvare tempo e budget per le attività di «conformità minima essenziale».
  • Richiedere una documentazione semplice: cosa usiamo, perché lo usiamo, come lo manteniamo aggiornato.

Profilo B

Responsabile tecnico

CTO / Lead developer / Responsabile DevOps

Obiettivo: attuare controlli pratici che riducano il rischio e possano essere mantenuti nel tempo.

  • Integrare la sicurezza nel ciclo di vita (revisione, test, rilasci sicuri, aggiornamenti).
  • Garantire la visibilità sulle dipendenze (SBOM, scansione delle dipendenze, tracciamento delle dipendenze transitive).
  • Attuare la gestione delle vulnerabilità (presa in carico, triage, processo di patching, note di rilascio).
  • Garantire la tracciabilità (disciplina di versionamento, changelog, branch protetti, controlli di accesso).

Profilo C

Product owner / coordinatore della conformità

Product manager / QA / Referente per la sicurezza

Obiettivo: collegare decisioni di prodotto, aspettative dei clienti ed evidenze di conformità.

  • Chiarire l’ambito del prodotto e l’uso previsto (dove si usa FOSS, dove c’è esposizione).
  • Applicare una visione basata sul rischio: quali componenti sono critici e quali a basso rischio.
  • Mantenere raccolte di evidenze leggere (decisioni sul rischio, registro dei componenti, cronologia degli aggiornamenti).
  • Coordinare i team affinché monitoraggio e aggiornamenti non restino scoperti tra un ruolo e l’altro.

Questi profili non si escludono a vicenda. In molte PMI una sola persona può ricoprire più ruoli. L’essenziale è che titolarità e responsabilità siano assegnate in modo esplicito.

Dal consumo ad hoc alla governance strutturata

Il CRA segnala una trasformazione più ampia: la conformità non si limita più alla progettazione interna del prodotto, ma si estende all’intera catena di approvvigionamento del software. Per le PMI, ciò implica il passaggio da un consumo ad hoc dell’open source a una governance dell’ecosistema strutturata e basata sul rischio.

Consumo ad hoc

Frammentato e manuale

Governance strutturata

Basata sul rischio e scalabile

Gli steward diventano attori chiave di questa architettura di governance, mentre l’utilizzo di componenti privi di uno steward sarà sottoposto a un esame approfondito per valutarne correttamente i rischi. Anziché verificare singolarmente ogni progetto a monte, le PMI possono:

  • Sfruttare processi allineati a quelli degli steward
  • Affidarsi a quadri di sicurezza strutturati
  • Documentare il coinvolgimento nell’ambito della due diligence
  • Dimostrare una gestione proporzionata e basata sul rischio

Questo approccio è in linea con l’intento del CRA: migliorare la cybersicurezza senza imporre oneri sproporzionati.

Due diligence per i componenti open source

L’integrazione di componenti FOSS in prodotti con elementi digitali introduce una responsabilità condivisa lungo la catena di approvvigionamento del software. Nel quadro basato sul rischio del CRA, i fabbricanti, comprese le PMI, sono tenuti ad applicare una due diligence adeguata e proporzionata nella selezione, nell’integrazione e nella manutenzione di componenti software di terze parti.

La due diligence non intende scoraggiare l’uso del software open source. Al contrario, il FOSS resta un fattore abilitante fondamentale per l’innovazione e la competitività, ma deve essere integrato in modo responsabile. La due diligence garantisce che:

Sai che cosa stai integrando

Conosci il livello di rischio che introduce

Puoi giustificare la tua decisione di integrazione

Sei in grado di monitorarlo e mantenerlo nel tempo

La due diligence non è un controllo una tantum prima del rilascio. È un’attività orientata al ciclo di vita che prosegue per tutta la durata di vita prevista del prodotto, in linea con i requisiti del CRA in materia di sviluppo sicuro e gestione delle vulnerabilità.

Valutazione dei componenti FOSS basata sul rischio

Prima di integrare un componente FOSS, le PMI dovrebbero valutare tre dimensioni chiave. Le domande sono pensate per essere comprensibili sia ai decisori tecnici sia a quelli non tecnici.

Criticità funzionale

Domande da porsi:

  • Questo componente gestisce autenticazione, crittografia, controllo degli accessi o aggiornamenti?
  • È centrale per le funzionalità principali del prodotto?
  • Se questo componente smettesse di funzionare, il nostro prodotto si bloccherebbe?
  • Potrebbe compromettere la riservatezza, l’integrità o la disponibilità dei dati?

Più la funzione è critica, più la valutazione deve essere accurata. Una libreria di logging non equivale a un modulo di autenticazione.

Livello di esposizione

Domande da porsi:

  • Questo componente è accessibile da Internet?
  • Elabora input provenienti da utenti esterni?
  • È esposto tramite API?
  • Oppure è completamente interno e isolato?

Una maggiore esposizione amplia la superficie di attacco. Un componente di utilità interno può richiedere una revisione più leggera rispetto a un componente di servizio esposto pubblicamente.

Impatto in caso di incidente

Domande da porsi:

  • Lo sfruttamento potrebbe causare violazioni di dati personali?
  • Un’interruzione del servizio avrebbe ripercussioni sui clienti?
  • Farebbe scattare obblighi di notifica alle autorità?
  • Potrebbe danneggiare la nostra reputazione?

L’impatto determina quanto impegno sia giustificato nella gestione del rischio.

Questi fattori vanno considerati insieme

  • Un componente moderatamente critico ma esposto pubblicamente può richiedere controlli rafforzati.
  • Un componente altamente critico usato solo internamente può giustificare una revisione strutturata ma proporzionata.

L’obiettivo è la proporzionalità, non un controllo uniforme.

Livelli proporzionati di due diligence

In linea con il principio di proporzionalità del CRA, le pratiche di due diligence possono essere articolate su livelli di maturità crescenti.

Livello 1

Due diligence di base

Adatta a componenti con bassa criticità ed esposizione limitata.

Le misure comprendono:

  • Verifica dell’attività del progetto e della manutenzione recente
  • Esame delle vulnerabilità divulgate pubblicamente
  • Verifica della compatibilità della licenza
  • Inclusione del componente nella distinta base del software (SBOM)

L’obiettivo è la trasparenza e la tracciabilità. Per molte PMI si tratta di una base realistica e raggiungibile, in linea con aspettative di conformità proporzionate.

Livello 2

Due diligence strutturata

Adatta a componenti con criticità o esposizione moderate.

Le misure aggiuntive possono comprendere:

  • Esame della trasparenza della governance e della struttura dei maintainer
  • Valutazione delle pratiche di segnalazione e risposta alle vulnerabilità
  • Valutazione della disciplina di rilascio e della chiarezza del versionamento
  • Strumenti automatizzati di scansione delle dipendenze

La due diligence strutturata introduce prevedibilità. Riduce il ricorso a decisioni ad hoc e sostiene valutazioni interne del rischio documentate.

Livello 3

Due diligence rafforzata

Adatta a componenti altamente critici o esposti pubblicamente.

Le misure rafforzate possono comprendere:

  • Monitoraggio continuo delle vulnerabilità
  • Esame delle pratiche di divulgazione coordinata
  • Valutazione dell’impegno di manutenzione a lungo termine
  • Considerazione delle attestazioni di sicurezza volontarie ai sensi dell’articolo 25
  • Coinvolgimento dei maintainer, ove opportuno

Particolarmente indicata per i componenti che:

  • Trattano dati sensibili
  • Sono esposti pubblicamente
  • Supportano funzionalità essenziali del prodotto
  • Operano in ambienti regolamentati o ad alto impatto

La due diligence rafforzata consolida la resilienza dell’intera catena di approvvigionamento del software.

Non sai quale livello si applica? La matrice decisionale combina criticità ed esposizione per raccomandarne uno. Nella sezione Checklist e modelli sono disponibili modelli a supporto dei livelli da 1 a 3.

Usa la matrice decisionale

Monitoraggio continuo e responsabilità lungo il ciclo di vita

La due diligence non termina al momento dell’integrazione. Le vulnerabilità possono essere scoperte anni dopo. I maintainer possono cambiare. I rilasci possono rallentare. La responsabilità lungo il ciclo di vita richiede una consapevolezza continua dell’evoluzione delle vulnerabilità e dello stato di manutenzione del progetto.

Le PMI dovrebbero

  • Monitorare le divulgazioni di vulnerabilità che riguardano le dipendenze incluse
  • Seguire i nuovi rilasci e gli aggiornamenti di sicurezza
  • Mantenere aggiornata la SBOM
  • Rivalutare il rischio quando cambiano l’esposizione o l’architettura

Rivalutare in particolare quando

  • Vengono introdotte nuove funzionalità del prodotto
  • L’esposizione pubblica aumenta
  • I requisiti normativi cambiano
  • L’attività di manutenzione a monte diminuisce

Questo approccio continuo è direttamente in linea con gli obblighi di sicurezza del CRA relativi al ciclo di vita.

Utilizzare le attestazioni di sicurezza

Ove disponibili, le attestazioni di sicurezza volontarie ai sensi dell’articolo 25 possono sostenere una due diligence strutturata. Le attestazioni possono:

  • Fornire informazioni standardizzate e confrontabili su governance e pratiche di sicurezza
  • Ridurre le richieste di conformità ripetitive rivolte ai maintainer
  • Facilitare l’integrazione nei processi interni di valutazione del rischio

La responsabilità dell'integratore resta

Affidarsi alle attestazioni non elimina la responsabilità dell’integratore. Le PMI devono valutare la pertinenza delle informazioni attestate rispetto al proprio contesto di integrazione, al livello di esposizione e all’architettura del prodotto. Le attestazioni aumentano la trasparenza ma non sostituiscono la valutazione del rischio nel contesto specifico.

Errori comuni e segnali d'allarme

Errori comuni nell’integrazione del FOSS

Le PMI incontrano spesso difficoltà ricorrenti:

  • Presumere che un’ampia diffusione implichi automaticamente la sicurezza
  • Non individuare le dipendenze indirette (transitive)
  • Effettuare una convalida una tantum senza monitoraggio continuo
  • Affidarsi alle patch a monte senza verificarne l’effettiva adozione
  • Integrare componenti senza documentare le ragioni della scelta

Riconoscere questi schemi consente alle PMI di passare da un’integrazione reattiva a una gestione strutturata del rischio.

Segnali d’allarme da tenere d’occhio

Indicatori che possono suggerire un rischio elevato:

  • Nessun canale visibile per la segnalazione di problemi di sicurezza
  • Lunghi periodi senza aggiornamenti o manutenzione
  • Vulnerabilità critiche irrisolte senza alcuna comunicazione
  • Versionamento o documentazione dei rilasci incoerenti
  • Mancanza di chiarezza sulle responsabilità dei maintainer
  • Alberi di dipendenze estesi e poco trasparenti

Un segnale d’allarme non squalifica automaticamente un componente. Tuttavia, la presenza di più indicatori può giustificare una due diligence rafforzata o un ripensamento della strategia di integrazione.

Checklist rapida di due diligence

Dodici semplici domande su visibilità di base, consapevolezza delle vulnerabilità, trasparenza della catena di approvvigionamento e aspetti legati al ciclo di vita. Un punto di partenza accessibile e proporzionato per le PMI con risorse limitate.

Apri la checklist

Il percorso delle PMI verso un'adozione del FOSS allineata al CRA

Il CRA è basato sul rischio e orientato al ciclo di vita. Le PMI possono adottare un approccio pratico seguendo un percorso semplice, che si adatta alla criticità del prodotto e alle risorse disponibili.

  1. Iniziare Definire le responsabilità e una visibilità di base

    • Assegnare la responsabilità per: selezione delle dipendenze, aggiornamenti di sicurezza, monitoraggio delle vulnerabilità e documentazione.
    • Creare un inventario minimo dei principali componenti FOSS utilizzati nel prodotto.

  2. Definire l'ambito Dove il FOSS conta nel tuo prodotto

    • Individuare le parti del prodotto esposte a Internet, che trattano dati o che sono sensibili dal punto di vista della sicurezza.
    • Chiarire quali componenti sono critici per le funzionalità del prodotto.

  3. Valutare il rischio Ragionare in modo proporzionato

    • Valutare ogni componente in base a: criticità, esposizione e impatto.
    • Decidere quale livello di due diligence sia ragionevole (di base / strutturata / rafforzata).

  4. Applicare controlli proporzionati Fare ciò che è appropriato

    • Per i componenti a basso rischio: controlli di base + SBOM + monitoraggio.
    • Per i componenti a rischio più elevato: verifiche strutturate della governance, una disciplina di rilascio più rigorosa, un monitoraggio più intenso.

  5. Monitorare Un'attività continua, non una tantum

    • Seguire le vulnerabilità e gli aggiornamenti a monte.
    • Aggiornare la SBOM a ogni rilascio (o almeno ai rilasci principali).
    • Assicurarsi che gli aggiornamenti vengano adottati tempestivamente.

  6. Rivalutare Quando qualcosa cambia

    • Il prodotto diventa più esposto (nuove integrazioni, esposizione a Internet).
    • Le funzionalità critiche cambiano.
    • La manutenzione a monte diminuisce.
    • Emergono nuove vulnerabilità che interessano dipendenze fondamentali.

Questo percorso è pensato per aiutare le PMI a dimostrare un approccio strutturato e difendibile, anche con risorse limitate.

Matrice decisionale per la due diligence dei componenti FOSS

Per favorire decisioni coerenti e proporzionate, la matrice combina due dimensioni, la criticità funzionale e il livello di esposizione, e raccomanda il livello di due diligence (L1 / L2 / L3) definito sopra.

Criticità funzionale Livello di esposizione InternaUso isolatoLimitataAccesso controllatoPubblicaEsposta a Internet
BassaL1 Di baseL1 Di baseL2 Strutturata
MediaL1 Di baseL2 StrutturataL3 Rafforzata
AltaL2 StrutturataL3 RafforzataL3 Rafforzata

Come usare questa matrice

  1. Determinare la criticità funzionale del componente:
    • Supporta funzionalità principali?
    • Gestisce autenticazione, crittografia o aggiornamenti?
    • Un suo malfunzionamento avrebbe un impatto significativo sul prodotto?
  2. Determinare il livello di esposizione:
    • È solo interno?
    • È accessibile tramite API autenticate?
    • È esposto pubblicamente?
  3. Individuare l’intersezione nella matrice per identificare il livello di due diligence raccomandato.

Considerazioni importanti

  • Questa matrice fornisce indicazioni, non una classificazione rigida.
  • Se l’impatto in caso di incidente è eccezionalmente elevato (ad esempio per la sicurezza delle persone o in un ambiente regolamentato), le PMI possono scegliere di applicare un livello di due diligence superiore.
  • La matrice favorisce la proporzionalità, evitando sia l’eccesso di ingegnerizzazione sia la sottovalutazione.

Torna su