Due componenti condividono lo stesso codice sorgente e la stessa licenza open source. Un’azienda terza li integra entrambi nei propri prodotti.
Il primo componente rende chi lo pubblica un fabbricante (manufacturer, nel testo inglese del regolamento) ai sensi del Cyber Resilience Act[1], con tutti gli obblighi che questo comporta. Il secondo no: chi lo pubblica resta, al più, un gestore di software open source (steward, nel testo inglese), soggetto a un regime molto più leggero.
La differenza non sta nel codice, non sta nella licenza e non sta nemmeno in chi scrive quel codice. Sta in un solo dato, spesso ignorato da chi valuta i fornitori open source prima di integrarli: se quello specifico progetto genera un ricavo per chi lo pubblica.
In questo intervento guardiamo al processo con cui le aziende valutano oggi i fornitori di componenti open source e cerchiamo di mostrare perché quel processo, così com’è impostato nella maggior parte dei casi, non risponde a una domanda che il CRA richiede di farsi.
Indice degli argomenti
Due diligence sui componenti open source nel CRA: i controlli che non bastano
Chi valuta un componente open source prima di integrarlo guarda tipicamente alla struttura di chi lo pubblica. Conta la dimensione dell’organizzazione, perché suggerisce continuità nel tempo. Conta la reputazione del progetto, misurata in stelle su un repository o in adozione diffusa. Conta la presenza di un’offerta di supporto commerciale visibile, perché segnala che dietro il codice c’è un’attività strutturata, non un singolo sviluppatore che potrebbe abbandonare il progetto senza preavviso.
Questi criteri hanno una loro logica operativa e rispondono a una domanda legittima: il fornitore reggerà nel tempo? Sarà raggiungibile se qualcosa va storto? Il punto è che, in base al CRA, queste domande non sono quelle corrette.
Il criterio del CRA per distinguere gestore e fabbricante
Il CRA qualifica come software libero e open source, ai fini del regolamento, solo il software il cui codice sorgente è condiviso apertamente e distribuito con una licenza che garantisce accesso, uso, modifica e ridistribuzione libera. Stabilito questo, il regolamento pone due domande in sequenza, entrambe indipendenti dalla dimensione o dalla reputazione di chi pubblica.
Responsabilità giuridica e controllo del progetto
La prima domanda è se quel software libero sia sotto la responsabilità di una persona giuridica, cioè se chi lo pubblica eserciti controllo effettivo su sviluppo, rilasci e decisioni di distribuzione. Chi si limita a contribuire codice, senza governare quelle decisioni, resta fuori dal perimetro del CRA su quel progetto, indipendentemente da quanto codice abbia scritto.
L’immissione sul mercato e la monetizzazione
La seconda domanda, quella decisiva per la distinzione tra gestore e fabbricante, è se chi pubblica quel software lo immette sul mercato nel corso di un’attività commerciale.
La guida della Commissione europea sull’applicazione del CRA, pubblicata il 27 luglio 2026[2], chiarisce che questa immissione sul mercato si misura sulla monetizzazione dello specifico progetto: un prezzo richiesto per il software stesso, un servizio di supporto il cui accesso condiziona l’uso del prodotto, il trattamento di dati personali richiesto come condizione d’uso per finalità diverse dalla sicurezza o dall’interoperabilità, donazioni che di fatto equivalgono a un prezzo perché condizionano l’accesso a funzionalità essenziali.
Dove nessuna di queste condizioni ricorre, il software non è considerato immesso sul mercato e chi lo pubblica, se ne assicura un supporto sistematico e continuativo, ricade nella categoria di gestore introdotta dall’articolo 3, paragrafo 14, del regolamento, soggetta solo agli obblighi, più contenuti, dell’articolo 24.
Nessuno di questi elementi coincide con la dimensione dell’organizzazione, la sua reputazione o la visibilità della sua offerta commerciale. Un’organizzazione grande e strutturata può non monetizzare uno specifico progetto e restare gestore su quello, pur essendo fabbricante su un altro.
Open source nel CRA: monetizzazione e qualifiche giuridiche
La guida della Commissione descrive un caso ricorrente nell’ecosistema open source, quello della doppia versione: una versione community, gratuita e una versione enterprise o paid, che estende la stessa base di codice o la incorpora in un prodotto più ampio (il cosiddetto modello open core).
Versioni community ed enterprise
Le due versioni condividono lo sviluppatore, l’infrastruttura, spesso anche gran parte del codice. Solo la versione monetizzata è considerata immessa sul mercato, con chi la pubblica che diventa fabbricante su quella. La versione community resta fuori e chi la pubblica, se ne garantisce comunque un supporto continuativo, resta gestore.
Il caso delle fondazioni non profit
Lo stesso effetto si presenta, in forma ancora più marcata, per le fondazioni non profit che ospitano e finanziano progetti open source.
Un’entità di questo tipo può ricevere finanziamenti regolari da aziende fabbricanti, gestire infrastrutture tecniche complesse, avere una struttura di governance articolata, tutti segnali che nella due diligence tradizionale suggerirebbero un fornitore solido e strutturato, quindi verosimilmente un fabbricante. Se quell’entità è costituita in modo tale che i proventi, dopo i costi, siano destinati a finalità non lucrative, il software che pubblica non è considerato immesso sul mercato, indipendentemente da quanto quella struttura assomigli, all’apparenza, a un’attività commerciale.
Un identikit di fornitore che sembra identico, quindi, può nascondere due qualifiche giuridiche opposte, o riguardare due prodotti dello stesso fornitore con status diversi. Una due diligence che si fermi al profilo organizzativo non è in grado di distinguerli.
L’obbligo di due diligence sui componenti di terzi
Vale la pena chiarire un punto che genera spesso confusione operativa: sapere che un componente open source non è immesso sul mercato non chiude la verifica, ma la sposta.
L’articolo 13, paragrafo 5, del CRA impone a chi integra componenti di terzi, inclusi componenti open source non soggetti essi stessi al regolamento, un obbligo autonomo di due diligence, distinto dalla valutazione del rischio informatico che l’articolo 13, paragrafo 2, richiede per il prodotto nel suo complesso.
Le verifiche tecniche richieste dall’articolo 13
Questo obbligo richiede di identificare cosa il prodotto si aspetta da quel componente in termini di sicurezza, per esempio funzioni crittografiche, meccanismi di aggiornamento o comunicazioni sicure e di verificare, con un approccio proporzionato al rischio indicato dal Considerando 34 del regolamento, che il componente soddisfi quei requisiti.
La guida della Commissione indica come evidenza utile la documentazione ottenuta da chi pubblica il componente, come specifiche tecniche o documentazione di sicurezza, oltre a test condotti direttamente dove opportuno.
Chi integra resta responsabile della conformità del prodotto finale, indipendentemente dal fatto che il componente integrato sia stato pubblicato da un fabbricante, da un gestore o da un singolo sviluppatore senza alcun obbligo sotto il CRA.
Cambia quindi cosa serve documentare, non se serve documentare qualcosa. Un componente pubblicato da un gestore richiede una due diligence che ne verifichi le proprietà tecniche di sicurezza con gli stessi criteri di un componente pubblicato da un fabbricante, anche se il gestore non è tenuto a fornire una dichiarazione di conformità.
La due diligence open source va aggiornata nel tempo
Il sottotitolo di questo articolo parla di un fornitore già approvato che risulta non conforme senza che nel frattempo sia cambiato nulla. Questo accade in due modi distinti, che è bene tenere separati.
Classificazioni errate e cambiamenti commerciali
Nel primo caso, la classificazione era sbagliata fin dall’inizio: la due diligence ha verificato dimensione, reputazione e supporto visibile, non monetizzazione dello specifico progetto e ha quindi archiviato come irrilevante un dato che era invece decisivo. Il fornitore non ha cambiato nulla: la valutazione, semplicemente, non ha mai guardato nel punto giusto.
Nel secondo caso il cambiamento c’è, ma avviene sul piano commerciale, non su quello tecnico e per questo sfugge ai controlli tarati sul codice. Un gestore che inizia a monetizzare direttamente il progetto che sosteneva diventa fabbricante da quel momento, per le versioni successive. Un gestore che smette di fornire supporto sistematico può uscire dalla categoria stessa di gestore, con conseguenze sugli obblighi residui.
Nessuno di questi passaggi produce una nuova release da sottoporre a revisione tecnica. Entrambi restano invisibili a un processo di due diligence pensato come controllo puntuale all’ingresso, anziché come verifica da ripetere nel tempo su un dato, quello della monetizzazione, che può cambiare senza che una sola riga di codice venga toccata.
Controlli periodici attivati dagli eventi
Rendere quella verifica periodica non significa moltiplicare gli audit. Significa legarla a eventi che la rendono necessaria, non al calendario: un cambio nel modello di licenza o nel piano tariffario del progetto, l’annuncio di una versione enterprise affiancata alla community, l’acquisizione del progetto o della fondazione che lo ospita da parte di un soggetto commerciale e la cessazione di un supporto che il gestore forniva prima con continuità.
Un registro dei fornitori open source che tracci, per ciascun componente, la data dell’ultima verifica di monetizzazione insieme alla versione integrata permette di individuare quali componenti richiedono un nuovo controllo senza dover rivedere l’intero parco fornitori a ogni scadenza.
Il calendario degli obblighi del CRA
Il termine per intervenire non coincide con l’entrata in applicazione piena del regolamento. Gli obblighi di segnalazione previsti dall’articolo 14 del CRA, quelli relativi a vulnerabilità attivamente sfruttate e a incidenti gravi che coinvolgono anche i componenti su cui si è esercitata la due diligence dell’articolo 13, paragrafo 5, si applicano già dall’11 settembre 2026. La gran parte degli altri obblighi, compresa la valutazione di conformità vera e propria, entra in applicazione l’11 dicembre 2027.
Chi rinvia la revisione della propria due diligence a quella data arriva comunque in ritardo sugli obblighi di segnalazione, che presuppongono di sapere già, con esattezza, quali componenti open source sono integrati nei propri prodotti e sotto quale regime ciascuno ricade.
Una due diligence sui componenti open source impostata sul profilo del fornitore, quindi, verifica la cosa sbagliata due volte: una alla prima valutazione, se il criterio non era quello corretto e una a ogni rinnovo, se il criterio corretto non viene ricontrollato periodicamente.
Riformulare quel processo significa spostare la domanda cardine dal chi pubblica il componente al come, oggi, quel componente specifico viene reso disponibile: a pagamento o gratuitamente, condizionato a un trattamento di dati o no, sostenuto da un’entità che ne trae profitto o da una che, per statuto, non può farlo.
È una domanda più stretta di quella abituale, ma è l’unica a cui il CRA chiede effettivamente di rispondere.
Note
[1] Regolamento (UE) 2024/2847 del Parlamento europeo e del Consiglio, del 23 ottobre 2024, relativo ai requisiti di cibersicurezza per i prodotti con elementi digitali (Cyber Resilience Act). ↩
[2] Guida della Commissione europea all’applicazione del CRA al software libero e open source, del 27 luglio 2026. Il riferimento come comunicazione C(2026) 5252 proviene dal materiale di confronto fornito dall’autore: se ne raccomanda la verifica sul testo pubblicato prima della diffusione dell’articolo. ↩
Partecipa alla community