Cyber Resilience Act: Che Cos'è E Perché È Una Minaccia Per Il Software Open Source in Europa

Il Cyber Resilience Act è una proposta di regolamento europeo che intende migliorare la cybersecurity dei prodotti con elementi digitali. A tal fine, la proposta di Regolamento prevede nuovi obblighi e responsabilità per chi scrive o distribuisce software. In questo articolo evidenziamo alcuni aspetti critici del Cyber Resilience Act, in particolare il forte disincentivo che introduce per lo sviluppo di software open source in Europa.

Cyber Resilience Act: la normativa

Il Cyber Resilience Act è una proposta di Regolamento Europeo che si propone di migliorare gli standard di cybersecurity dei prodotti con elementi digitali. Prodotti più sicuri limiterebbero gli incidenti o attacchi informatici che causano ogni anno danni enormi all'economia.

Con questo articolo vediamo cosa prevede il Cyber Resilience Act, come intende aumentare la cybersicurezza e perché rappresenta un forte disincentivo allo sviluppo di software opensource in Europa. Prenderemo in esame la bozza del Cyber Resilience Act al momento disponibile (pdf della versione in Italiano).

Ambito di applicazione

Il Regolamento Cyber Resilience Act:

SI APPLICA a tutti i prodotti con elementi digitali il cui uso prevede una diretta o indiretta connessione logica o fisica ad un dispositivo o rete.

NON SI APPLICA ai prodotti con elementi digitali già disciplinati dai Regolamenti:

1. 2017/745 : dispositivi medici;
2. 2017/746 : dispositivi medico-diagnostici in vitro;
3. 1139/2018 in materia di aviazione civile e già oggetto della certificazione da questo prevista;
4. 2019/2144 relativo alla omologazione dei veicoli a motore e dei loro rimorchi, nonché di sistemi, componenti ed entità tecniche destinate a tali veicoli.

Valutazioni di conformità e certificazioni

Il Cyber Resilience Act individua con l'allegato I dei requisiti minimi di cybersecurity per i prodotti con elementi digitali e prevede l'obbligo di produrre una valutazione di conformità che attesti il rispetto di tali requisiti.

La valutazione di conformità:

• potrà, a seconda dei casi, essere effettuata direttamente dal produttore o dovrà necessariamente coinvolgere terze parti.
• richiede modalità diverse a seconda se i prodotti siano considerati critici o altamente critici secondo la distinzione operata dall'allegato 3.

Prodotti critici

I prodotti critici vengono elencati e distinti in due categorie (I e II) dall'allegato 3 in base al grado di rischio che presentano sotto il profilo della cybersecurity, maggiore per la categoria II.

• Categoria I: la valutazione di conformità può essere effettuata dal produttore secondo la procedura prevista per questi prodotti.
• Categoria II: è prevista una modalità diversa che richiede l'intervento di terze parti.

Prodotti altamente critici

La Commissione Europea potrà integrare il Regolamento individuando categorie di prodotti altamente critici, ritenuti tali a seguito di una valutazione che consideri:

• la sussistenza dei profili di rischio già individuati dall'allegato 3 per i prodotti critici;
• il caso in cui i prodotti in questione siano:
  • utilizzati dai soggetti definiti essenziali dall'allegato 1 alla direttiva NIS2.
  • rilevanti per la resilienza dell'intera catena di approvvigionamento dei prodotti con elementi digitali contro eventi perturbatori.

Per i prodotti altamente critici i produttori dovranno ottenere una apposita certificazione, rilasciata secondo le modalità previste dal Regolamento UE sulla cibersicurezza 2019/881, che attesti il rispetto dei requisiti minimi di cui all'allegato I.

Presunzione di conformità

La conformità al regolamento di un prodotto con elementi digitali è presunta se:

1. il prodotto con elementi digitali è conforme alle norme armonizzate o a parti di esse, i cui riferimenti sono stati pubblicati nella Gazzetta ufficiale dell'Unione europea;
2. il prodotto ha già ricevuto una certificazione o dichiarazione di conformità secondo il sistema Europeo di certificazione della cybersicurezza previsto dal Regolamento UE 2019/881 e la Commissione specifichi che tale certificazione sia sufficiente ai fini dei requisiti previsti dalla proposta di Regolamento in esame.

Obblighi degli operatori economici

Il destinatario degli obblighi e delle responsabilità previste dalla proposta di regolamento è l'"operatore economico", individuato come il fabbricante, rappresentante autorizzato, importatore o distributore. Vedremo in seguito se è possibile definire con maggior precisione questi soggetti.

Conformità ai requisiti essenziali di cybersecurity

La proposta di Regolamento Cyber Resilience Act richiede che i prodotti con elementi digitali vengano messi sul mercato solo se soddisfano i requisiti essenziali di cybersicurezza previsti dal Regolamento all'allegato I. A tal fine, il fabbricante è tenuto ad effettuare la valutazione di conformità che abbiamo visto poc'anzi.

Inoltre, nella progettazione e produzione è richiesto al fabbricante di esercitare la dovuta diligenza sugli aspetti di sicurezza durante la progettazione e lo sviluppo dei loro prodotti, di essere trasparenti sugli aspetti di cibersicurezza che devono essere resi noti ai clienti, di garantire assistenza di sicurezza (aggiornamenti) in modo proporzionato e di soddisfare i requisiti di gestione delle vulnerabilità.

Software "non finito"

Infine, secondo il considerando 21 e l'articolo 4 è ammessa ma limitata la diffusione di software non finito; ad esempio una versione beta può essere rilasciata a condizione che:

1. sia messa in circolazione per il solo tempo necessario a testarla e a raccogliere i riscontri;
2. ci sia una preventiva valutazione dei rischi e, per quanto non finito, il software rilasciato sia conforme ai requisiti essenziali di sicurezza;
3. il produttore soddisfi i requisiti di gestione delle vulnerabilità.

Gestione delle vulnerabilità

L'articolo 10 prevede che il fabbricante garantisca il rispetto dei requisiti per la gestione delle vulnerabilità elencati dall'allegato I al punto 2, per 5 anni o per la durata del ciclo di vita del prodotto, a seconda di quale sia il periodo più breve.

Tuttavia, risulta sia stata presentata di recente una nuova bozza che rimuove il limite di 5 anni estendendo, per un tempo indefinito, la durata dell'obbligo in argomento.

Sanzioni

Agli obblighi previsti dalla proposta di regolamento fanno riscontro delle sanzioni, previste dall'articolo 53:

La non conformità ai requisiti essenziali di cibersicurezza di cui all'allegato I e agli obblighi di cui agli articoli 10 e 11 è soggetta a sanzioni amministrative pecuniarie fino a 15 000 000 di EURO o, se l'autore del reato è un'impresa, fino al 2,5 % del fatturato mondiale totale annuo dell'esercizio precedente, se superiore.

Articolo 53 Cyber Resilience Act

Ma chi è l'operatore economico destinatario di obblighi e sanzioni?

La definizione di operatore economico è data dall'articolo 3, al punto 17:

"operatore economico": il fabbricante, il rappresentante autorizzato, l'importatore, il distributore o qualsiasi altra persona fisica o giuridica soggetta agli obblighi stabiliti dal presente regolamento;

Articolo 3 punto 17 Cyber Resilience Act

La definizione è piuttosto vaga; non aiuta il fatto che si cerchi di completare la definizione e spiegare chi sia l'operatore economico soggetto al regolamento facendo riferimento a...chiunque sia soggetto al regolamento.

Per quanto vaga, è abbastanza chiaro che il regolamento si applichi a chiunque produca e distribuisca software, come indicato dai punti successivi dello stesso articolo 3:

"fabbricante": qualsiasi persona fisica o giuridica che sviluppi o fabbrichi prodotti con elementi digitali o che faccia progettare, sviluppare o fabbricare prodotti con elementi digitali e li commercializzi con il proprio nome o marchio, a titolo oneroso o gratuito;

articolo 3 - punto 18

Si noti poi che gli obblighi e le responsabilità del fabbricante vengono estesi dall'articolo 16 a chiunque apporti una modifica sostanziale al prodotto con elementi digitali.

Una persona fisica o giuridica, diversa dal fabbricante, dall'importatore o dal distributore, che apporta una modifica sostanziale al prodotto con elementi digitali è considerata un fabbricante ai fini del presente regolamento.

Articolo 16

Anche qui, non viene precisato quando una modifica possa dirsi sostanziale e giustificare così l'estensione della disciplina in esame a chi abbia solo modificato il codice scritto da altri. Un punto non da poco che lascerebbe uno sviluppatore nell'incertezza sul fatto di essere o meno tenuto al rispetto delle disposizioni del Cyber Resilience Act.

"rappresentante autorizzato": qualsiasi persona fisica o giuridica stabilita nell'Unione che abbia ricevuto da un fabbricante un mandato scritto che la autorizza ad agire per suo conto in relazione a determinati compiti

Articolo 3 - punto 19

"importatore": qualsiasi persona fisica o giuridica stabilita nell'Unione che immette sul mercato un prodotto con elementi digitali recante il nome o il marchio di una persona fisica o giuridica stabilita al di fuori dell'Unione

Articolo 3 - punto 20

"distributore": qualsiasi persona fisica o giuridica nella catena di approvvigionamento, diversa dal fabbricante o dall'importatore, che mette a disposizione un prodotto con elementi digitali sul mercato dell'Unione senza modificarne le proprietà;

Articolo 3 - punto 21

Perché il Cyber Resilience Act è una minaccia per il software open source

Abbiamo fin qui presentato alcuni aspetti della normativa; passiamo ora ad analizzarne le criticità ed in particolare vediamo perché la proposta di regolamento Cyber Resilience Act rappresenta una minaccia per lo sviluppo di software open source, per la competitività dell'Europa in un settore cruciale per l'innovazione e paradossalmente per la stessa cybersecurity.

Un deterrente per gli sviluppatori

Tra i soggetti destinatari degli obblighi e delle sanzioni previste dal regolamento c'è chiunque sviluppi software, anche gratuitamente. Un progetto open source è normalmente un'opera a cui contribuiscono tanti sviluppatori che scrivono e foniscono il proprio codice, perlopiù in maniera gratuita, che viene riutilizzato nell'ambito di uno o vari altri progetti.

Chi mai vorrebbe contribuire ad un progetto open source gratis, accettando per giunta la possibilità che altri ne traggano profitto, per poi essere soggetto ad adempimenti e pesanti sanzioni?

Il solo fatto di contribuire con il proprio codice, in ragione della ampia definizione di fabbricante fornita dal regolamento, rende necessario effettuare le valutazioni di conformità e relative procedure che, a seconda del progetto, possono coinvolgere anche terze parti e, immaginiamo, risultare particolarmente onerose.

Ad esempio: tra i prodotti critici di seconda categoria, elencati dall'allegato 3, ci sono i sistemi operativi per desktop, server e dispositivi mobili. Pensiamo ora ad uno dei più noti successi dell'open source, il sistema operativo Linux nelle sua tantissime varianti, al cui sviluppo contribuiscono tanti singoli sviluppatori, oltre che grandi aziende. Ogni sviluppatore sarebbe soggetto agli obblighi previsti dal Cyber Resilience Act per il fabbricante, tra cui gli adempimenti relativi alla valutazione di conformità, particolarmente esigenti in considerazione della inclusione dei sistemi operativi tra i prodotti critici della seconda categoria.

Inoltre, l'estensione degli obblighi del fabbricante, operata dall'articolo 16, a chiunque apporti una modifica sostanziale al prodotto con elementi digitali, lascia un grado di incertezza circa il fatto di essere o meno soggetti al regolamento: anche questo è più facile che convinca uno sviluppatore ad impiegare il proprio tempo diversamente invece che contribuire allo sviluppo di un software open source.

Un ostacolo per le piattaforme di condivisione del software

Piattaforme come Github rappresentano uno strumento utile e potente per la produzione di software open source: gli utenti pubblicano il loro codice e condividono lo sviluppo di un progetto. La piattaforma di condivisione del software consente questo lavoro di squadra ospitando e rendendo disponibile il codice scritto dagli utenti.

Secondo la definizione del Cyber Resilience Act piattaforme come Github sono distributori e in quanto tali sono soggetti agli obblighi previsti dall'articolo 14, in particolare dal comma 2:

Prima di mettere un prodotto con elementi digitali a disposizione sul mercato, i distributori verificano che:

1. il prodotto con elementi digitali rechi la marcatura CE;
2. il fabbricante e l'importatore abbiano rispettato gli obblighi previsti rispettivamente dall'articolo 10, paragrafi 10 e 11, e dall'articolo 13, paragrafo 4.

articolo 14 Comma 2 - Cyber Resilience Act

Questo vuol dire che le piattaforme saranno responsabili del software pubblicato, dovendo controllare che gli autori siano o meno tenuti all'osservanza del regolamento e, in caso affermativo, abbiano ottemperato agli obblighi da questo previsti. È ragionevole aspettarsi che anche questo si risolva in un disincentivo per le piattaforme in argomento a fornire i propri servizi in Europa.

Una contraddizione per le licenze open source

Oltre a dissuadere dalla partecipazione ad un progetto open source donando il proprio codice, le disposizioni del Cyber Resilience Act contraddicono i termini e il senso stesso delle licenze open source: il codice viene fornito "as is" without warranty of any kind, senza alcuna garanzia. In tal senso, vedi l'articolo 15 della licenza GPLv3: "disclaimer of warranty".

Il fine delle licenze open source è infatti quello di motivare gli sviluppatori a contribuire, non dissuaderli; la responsabilità per la qualità del codice potrebbe ricadere al massimo su chi decide di riutilizzarlo e commercializzarlo, non su chi lo dona.

Ma non c'è una deroga per chi produce software open source?

Un "tentativo di deroga" è previsto dal considerando 10, che da un lato non basta, dall'altro meriterebbe di essere precisato in un articolo apposito, invece che confinato ad un considerando.

Secondo il considerando 10 alla proposta di Regolamento:

Al fine di non ostacolare l'innovazione o la ricerca, il presente regolamento non dovrebbe disciplinare il software libero e open source sviluppato o fornito al di fuori di un'attività commerciale. Ciò vale in particolare per il software (compresi il codice sorgente e le versioni modificate) condiviso apertamente e liberamente accessibile, utilizzabile, modificabile e ridistribuibile.

Il perché non basta lo si intende dalla definizione di attività commerciale fornita in seguito dal considerando:

Nel contesto del software, un'attività commerciale può essere caratterizzata non solo dall'applicazione di un prezzo per un prodotto, ma anche dall'applicazione di un prezzo per i servizi di assistenza tecnica, dalla fornitura di una piattaforma software attraverso la quale il fabbricante monetizza altri servizi o dall'utilizzo di dati personali per motivi diversi dal solo miglioramento della sicurezza, della compatibilità o dell'interoperabilità del software.

Nella definizione di attività commerciale ricade proprio il modello di business adottato da tante aziende ed operatori del settore open source: il software viene fornito gratis, ma l'utente paga per servizi aggiuntivi come l'assistenza tecnica, la formazione o anche il merchandising.

Esemplare in tal senso, è stata la Python Software Foundation: The EU's proposed CRA law may have unintended consequences for the Python Ecosystem

"Under the current language, the PSF could potentially be financially liable for any product that includes Python code, while never having received any monetary gain from any of these products. The risk of huge potential costs would make it impossible in practice for us to continue to provide Python and PyPI to the European public."

In breve: a questi termini, andiamo via dall'Europa. Non mettiamo più a disposizione degli utenti Europei i repository con il codice Python.

Limiti alla circolazione di versioni beta

Abbiamo visto come la diffusione del software definito incompleto venga limitata e si impongano comunque responsabilità ed adempimenti in capo a chi rilascia il codice a scopo di test.

Anche questo risulta in netto contrasto con le modalità con cui il software viene sviluppato, migliorato e reso più sicuro: incoraggiando gli utenti ad utilizzare il software, trovare bug e a sottoporre i propri feedback. Quanto più un software in via di sviluppo circola, tanto meglio verrà testato e depurato da eventuali vulnerabilità.

Che si tratta di una versione beta o alpha e dunque in via di sviluppo viene reso noto da chi lo mette in circolazione e questo di regola basta ad evitare che il software ancora "acerbo" venga usato in "produzione", ossia in contesti in cui è fondamentale ridurre i rischi di incidenti dovuti a possibili vulnerabilità.

Questo ci porta ad un'altra considerazione.

La proposta di regolamento parla di software incompleto: già la terminologia scelta denota scarsa dimestichezza con il modo in cui oggi viene sviluppato un software. Lo sviluppo di un programma informatico è costante ed accompagna tutto il suo ciclo di vita con il rilascio periodico di aggiornamenti, che si tratti di patch, ossia correzioni volte ad eliminare vulnerabilità, o nuove funzionalità. Quando si può dire che il lavoro è terminato e il software è completo, escludendo l'eventualità che possano emergere nuove vulnerabilità?

Conclusioni

Abbiamo fin qui illustrato i tratti principali della proposta di regolamento Cyber Resilience Act e in particolare il perché si tratti di una misura dannosa per l'open source in Europa. Di seguito ne riassumiamo le ragioni.

1 - Eccessivi costi di compliance: lo sforzo di compliance richiesto agli operatori economici finisce per essere sostenibile solo dalle grandi aziende, che magari sviluppano tutto il software al proprio interno, risultando invece molto gravoso e demotivante per i singoli sviluppatori che intendono (o meglio intenderebbero) contribuire a progetti open source.

2 - Perdita di competitività: la capacità di produrre software open source in Europa verrebbe limitata, a tutto vantaggio delle realtà non europee, in particolare di grandi società che non avrebbero problemi al rispetto della normativa, a dotarsi delle certificazioni richieste e ad immettere sul mercato europeo il software da loro prodotto. Il rischio è quello di dover acquistare altrove quello che non è più possibile produrre in casa.

3 - Meno cybersecurity: rendendo la vita difficile a chi sviluppa software open source si finisce per avere meno cybersecurity, invece che di più. Il modello open source deve il suo successo proprio alla partecipazione: l'accessibilità del codice consente ed incentiva l'apporto di più persone che, lavorando insieme, rendono un software di maggiore qualità e più sicuro. L'imposizione di nuovi obblighi e la minaccia di pesanti sanzioni non rappresenta certo un invito a contribuire a migliorare la sicurezza di un software o a risolvere una vulnerabilità appena riscontrata.

Vincenzo Lalli

Di formazione legale, appassionato da sempre di tecnologia ed informatica; esperienza professionale acquisita a cavallo tra i due mondi, finora piuttosto lontani tra loro. Mi dedico ad esplorare le crescenti interazioni tra il Diritto e la tecnologia, e a dare il mio contributo alla causa dell'innovazione nel settore legale; a tal fine, ho dato vita ad Avvocloud.net.

Contatti