Il Cyber Resilience Act, la competitività Europea e la sovranità digitale dell'UE

Da un articolo scritto da Mirko Boehm, Community Development Senior Director della Linux Foundation Europe, pubblicato sul blog della fondazione

La fondamentale importanza del software open source nel panorama dei prodotti digitali moderni, che ce ne sia coscienza o meno, sottolinea quanto le decisioni normative ad esso correlate abbiano un impatto pervasivo. Tale impatto non si limita solo agli attori direttamente coinvolti, come i produttori di software, le aziende tecnologiche, gli sviluppatori e i fornitori, ma si estende anche alle imprese e ai cittadini europei in generale. Questo rende il Cybersecurity Act (CRA), integrante della strategia dell'Unione Europea per la sicurezza informatica, di vitale importanza in questo momento storico.

La mancanza di cybersecurity è un problema reale

La mancanza di sicurezza informatica causa danni reali a tutta la filiera e alla sua economia:

• il ransomware sfrutta le vulnerabilità per impedire alle organizzazioni di utilizzare i propri sistemi; 
• le vulnerabilità della catena di fornitura iniettano componenti difettosi o violati in una moltitudine di prodotti;
• l'interruzione degli aggiornamenti di sicurezza e di manutenzione che causano l’obsolescenza dei prodotti digitali prima del tempo hanno l’effetto secondario, ma non meno importante, di creare inutile inquinamento e un aumento dei costi per i consumatori. Inoltre, pochi dispositivi digitali sono corredati da un'adeguata distinta base del software (SBOM) con l’obiettivo di informare ance il consumatore finale, così come le informazioni sul FOSS richieste dalla maggior parte delle licenze open source sono a volte lacunose.

La comunità open source ha identificato questi problemi per tempo e, ad esempio, ha agito istituendo la Core Infrastructure Initiative, che si è poi evoluta nella Open Source Security Foundation (OpenSSF). 

Con la proposta di regolamento sulla ciberresilienza, la Commissione europea intende da una parte migliorare la sicurezza informatica dei prodotti digitali e dall’altra consentire ai consumatori di fare scelte più informate nella scelta e nell'utilizzo dei prodotti digitali, che si intenda hardware o software. Ovviamente il fatto che la sicurezza informatica diventi una priorità dell'UE è stato accolto con favore da una moltitudine di parti interessate, tra cui la Linux Foundation e la Linux Foundation Europe. Il modo in cui il CRA intende aumentare il livello di sicurezza informatica, tuttavia, continua a suscitare grandi preoccupazioni.

LEGGI ANCHE: Il Cyber Resiliency Act e le Preoccupazioni per l'Open Source

Cosa propone il CRA?

Gli obiettivi principali del CRA sono ridurre le vulnerabilità dei prodotti digitali, garantire il mantenimento della cibersicurezza durante l'intero ciclo di vita di un prodotto e consentire agli utenti di prendere decisioni informate quando lo scelgono e lo utilizzano. A tal fine crea condizioni che si applicano a qualsiasi prodotto in rete immesso nel mercato dell'UE, sia esso fornito da un'azienda dell'UE o da un'azienda esterna, e ai prodotti non conformi al CRA sarà precluso l'accesso al mercato dell'UE. 

Il CRA distingue tra prodotti non critici e prodotti critici. Questi ultimi sono suddivisi in classe I e II. La classe II (router, firewall o processori di crittografia, ad esempio)  è soggetta ai requisiti di sicurezza informatica più severi. Le tecnologie open source fondamentali, come i sistemi operativi per server, desktop e dispositivi mobili, gli hypervisor o i runtime dei container, sono esplicitamente incluse nella classe II dei prodotti critici.

Software open source e sicurezza informatica nella Supply Chain dei prodotti

Ogni prodotto di consumo nasce come componente che attraversa la catena di fornitura in un processo di ulteriore integrazione.

Tecnicamente, il processo inizia con l'estrazione delle materie prime dal terreno e la fornitura di energia elettrica da una fonte di energia come una rete o un pannello solare. Per i prodotti con elementi digitali, le fasi rilevanti iniziano con l'assemblaggio dei moduli di livello più basso a partire da componenti software e hardware di uso generale. Si tratta delle materie prime equivalenti dell'ecosistema ICT, librerie software generiche e componenti elettrici di base. I componenti generici sono adatti a potenzialmente molte applicazioni, ma non ancora integrati per un uso specifico prevedibile. I prodotti pronti per il consumatore, invece, sono realizzati per un'applicazione concreta, dove il produttore promette l'idoneità allo scopo per cui il consumatore paga. Il processo di integrazione può essere seguito lungo la catena di fornitura, in quanto i prodotti intermedi vengono sempre più perfezionati fino a quando non sono pronti per il consumatore per lo scopo previsto.

Il software in quanto tale, sia esso in codice sorgente o in forma eseguibile, non descrive completamente un prodotto digitale. Facendo riferimento a Turing, per esaminare il comportamento di un prodotto digitale è necessario conoscere il software, l'ambiente hardware e la configurazione attuale del sistema. Questo aspetto è particolarmente importante nel contesto della sicurezza informatica: una vulnerabilità si concretizza solo quando una falla del software viene esposta dalla configurazione di uno specifico sistema in esecuzione. Il sistema concreto è necessario per riprodurre il problema. La correzione della vulnerabilità può essere verificata solo sul sistema concreto. In pratica, l'ambiente hardware spesso non è disponibile per la comunità di sviluppo del software a monte. Uno dei motivi è l'uso pervasivo di componenti open source in un numero spropositato di casi d'uso, da dispositivi banali a satelliti. Un altro motivo è la protezione della proprietà intellettuale: un produttore a valle non ha bisogno di divulgare i propri progetti hardware per poter utilizzare il software a monte. 

La decisione di utilizzare o meno un componente open source a monte viene presa dai produttori di prodotti lungo la Supply Chain. Nel progettare i loro sistemi, i produttori devono assicurarsi che il loro prodotto soddisfi i requisiti qualitativi e normativi, compresa la sicurezza informatica, per l'uso prevedibile da parte dell'attore successivo nella catena di fornitura. Il produttore del prodotto finale garantisce che il prodotto è sicuro per l'uso da parte del consumatore e soddisfa il suo scopo. Questa responsabilità end-to-end è supportata da accordi contrattuali tra i produttori di prodotti di consumo e i loro fornitori che gestiscono le garanzie e le responsabilità per i prodotti intermedi. Il consumatore può essere certo che il produttore del prodotto garantisce il sistema nel suo complesso e spesso non è a conoscenza dei componenti che lo compongono.

Le comunità open source a monte rilasciano software di uso generale con licenze che consentono l'uso, la modifica e la ridistribuzione da parte di chiunque, per qualsiasi scopo, ma senza alcun tipo di garanzia. Ciò pone queste comunità in una posizione speciale nella catena di fornitura del software: in quanto fornitori dei componenti più generici e riutilizzabili, l'utilizzo del software non richiede ai produttori a valle di impegnarsi con le comunità a monte. Il "prelievo" di software dai progetti open source è una transazione unilaterale da parte degli utenti a valle. Le comunità a monte, nella maggior parte dei casi, non conoscono a fondo gli utenti del loro software. A volte questo concetto è oscurato dalle aziende che rilasciano software open source e forniscono servizi commerciali intorno ad esso.

La cartina di tornasole, tuttavia, è semplice: se un consumatore può usare, modificare e ridistribuire il software senza impegnarsi con l'azienda, queste due attività sono separate e disgiunte. Questo vale per tutte le licenze open source accettate. I servizi sono un'attività commerciale, mentre i contributi a monte diventano parte del pool di software open source disponibile (il "global open source commons"). I contributori open source possono essere ovunque nel mondo e i loro contributi sono integrati a monte.

Il CRA si delinea come un ostacolo all'innovazione per le PMI europee

Nella bozza attuale, il CRA ignora queste realtà. Tratta tutto lo sviluppo e la distribuzione di prodotti digitali allo stesso modo. Non distingue tra i prodotti venduti nel mercato dell'UE e il rilascio di software con licenza open source.

Definisce invece un'esclusione per il software open source "sviluppato o fornito al di fuori del corso di un'attività commerciale" per non ostacolare l'innovazione o la ricerca. Purtroppo, questo è completamente fuori strada: la stragrande maggioranza del software open source è sviluppata nel corso di attività commerciali da sviluppatori nel loro lavoro quotidiano.

La stessa azienda o lo stesso sviluppatore possono lavorare su prodotti o fornire servizi commerciali mentre forniscono contributi all'open source. È la natura dell'attività che conta, non la persona che la svolge. Il CRA, inoltre, non tiene conto dell'uso previsto dal produttore nel definire le responsabilità per la sicurezza informatica.

Ciò significa che il fornitore di qualsiasi modulo software, open source o meno, può diventare responsabile delle vulnerabilità quando il software viene utilizzato per controllare una centrale nucleare, anche se il software è stato realizzato per i giocattoli.

Questo scollamento artificiale tra le decisioni sui prodotti, come il consumo di open source per immettere un prodotto sul mercato, e le loro conseguenze (le capacità di sicurezza informatica di questi ultimi) rappresenta una drastica deviazione dalle norme altrimenti consolidate nel mercato unico dell'UE e in altre parti del mondo. Pervertirà gli incentivi per i produttori, che cercheranno di scaricare la sicurezza informatica sui loro fornitori e sulle comunità a monte. Inoltre, comprometterà la capacità delle comunità di rendere disponibile il software nell'UE mantenendo in vita il loro modello di sviluppo open source.

Il modello di sviluppo open source ha molte varianti e il modo in cui il codice open source fluisce non è facile da capire per una persona esterna.

• L'ipotesi che gli sviluppatori che conoscono meglio il codice e sono più adatti a correggere le vulnerabilità si trovino a monte, da dove provengono i componenti open source. Questa nozione è stata utilizzata per spiegare l'idea che le comunità a monte dovrebbero essere responsabili della sicurezza informatica dei prodotti digitali derivati dai loro progetti. Il malinteso è che, mentre i contributi finiscono per essere integrati nei progetti a monte, quasi tutti gli sviluppatori che contribuiscono siedono a valle (downstream), cioè nelle aziende che creano i prodotti finali. Trovano problemi, vulnerabilità e potenziali miglioramenti del codice mentre integrano il software in prodotti più specializzati. Per fare un esempio ipotetico, i migliori sviluppatori di driver per GPU per il kernel Linux, in grado di risolvere i problemi di sicurezza, non lavorano per la Linux Foundation. Lavorano per le aziende produttrici di GPU che contribuiscono alle modifiche a monte del kernel Linux. Nel loro lavoro presso le aziende commerciali di GPU, hanno accesso a specifiche hardware e firmware proprietari che la comunità open source non ha. Sono nella posizione migliore per risolvere un ipotetico problema di sicurezza del driver della GPU.
• L'ipotesi che le fondazioni open source siano grandi, ben finanziate e di facciata per le grandi aziende tecnologiche e quindi in grado di finanziare team di sicurezza dedicati ai loro progetti. In generale, le fondazioni sono finanziate per facilitare la collaborazione tra le comunità. La stragrande maggioranza delle fondazioni open source non impiega i collaboratori tecnici. La Linux Foundation, in quanto maggiore facilitatore globale dello sviluppo open source, rende conto in modo trasparente del proprio bilancio: A partire dal 2022, raccoglie un budget complessivo di 243,57 milioni di dollari (pagina 138), di cui spende oltre il 90% (stessa pagina) per sostenere oltre 950 progetti. Molti dei progetti non hanno alcun finanziamento, ma anche se si distribuiscono i fondi su tutti i progetti, con poco più di 250.000 dollari per progetto, sono forse sufficienti per assumere un community manager e organizzare un paio di incontri. Non è certo sufficiente per assumere personale di sicurezza a tempo pieno. Inoltre, la Linux Foundation riceve questi fondi in base a contratti che prevedono il finanziamento di un progetto specifico (fondi diretti dai donatori). Nemmeno la Linux Foundation potrebbe decidere di dirottare quei fondi per sostenere il problema della sicurezza di qualche altro progetto. Altre fondazioni open source potrebbero essere ancora meno finanziate. In un momento in cui la sostenibilità a lungo termine di molti progetti open source è messa seriamente in dubbio da alcuni collaboratori, caricare di ulteriori oneri i maintainer dell'open source appare nel migliore dei casi controproducente. Anche se tutti i numeri possono sembrare grandi, semplicemente non c'è corrispondenza tra la situazione dei finanziamenti di una tipica comunità open source e quella delle imprese commerciali.

Se il CRA entrerà in vigore senza che queste preoccupazioni vengano affrontate, imporrà costi all'uso e ai contributi open source che sono principalmente a carico delle imprese e delle comunità europee. Le imprese al di fuori dell'UE dovranno conformarsi al CRA quando i loro prodotti saranno introdotti nel mercato unico dell'UE. In confronto, tutte le fasi della catena di approvvigionamento delle imprese con sede nell'UE devono implementare le normative comunitarie. Questo svantaggio competitivo scoraggerà i contributi commerciali open source provenienti dall'UE. Gli obblighi aggiuntivi demotivano i singoli contributori e maintainer. Le piccole comunità e i progetti a singolo maintainer, che sono i focolai dell'innovazione software nell'UE, potrebbero abbandonare del tutto l'Europa. In questo modo, il potenziale creativo che alimenta la formazione di startup europee verrà affamato. Inoltre, svantaggerà soprattutto le piccole e medie imprese (PMI), che si affidano all'innovazione open source a ritmo serrato per contrastare i grandi operatori storici che hanno le capacità finanziarie e amministrative per gestire gli obblighi aggiuntivi.

La bozza del CRA riconosce persino questo aspetto, invocando un fondo di sostegno alle PMI dell'UE. Ma anche un fondo di sostegno massiccio non può contrastare l'incapacità degli innovatori di iniziare a lavorare nell'UE a causa dell'accesso regolamentato al software open source con cui il resto del mondo è libero di innovare e competere rapidamente. In sintesi, il Cyber Resilience Act impone un ostacolo all'innovazione open source che sarà sopportato principalmente dalle PMI dell'UE e che arresta le capacità di innovazione dei prodotti digitali dell'UE.

... tutto ciò è in contrasto con gli obiettivi strategici dell'UE in materia di tecnologia

Il recente studio sull'impatto economico dell'open source in Europa evidenzia che l'innovazione del software europeo è in gran parte guidata dalle PMI e dalle comunità open source. La maggior parte delle aziende software "big-tech" ha sede al di fuori dell'UE. Un risultato potenzialmente disastroso del CRA potrebbe essere il rifiuto delle comunità open source di rendere disponibile il software nell'UE. Il software open source sarebbe quindi disponibile in Europa solo attraverso intermediari commerciali. La maggior parte delle aziende destinate ad assumere questo ruolo - principalmente i distributori di Linux e i produttori di kit di sviluppo per dispositivi - non hanno sede nell'UE. Sebbene questo comportamento (rilasciare il software con una licenza libera e lasciare la distribuzione a valle) sia chiaramente in linea con il modello di sviluppo open source, significa che il costo del CRA dell'UE potrebbe essere pagato anche a grandi aziende tecnologiche al di fuori dell'UE.

In questo modo, il CRA rischia di andare contro il modo in cui l'UE intende adottare l'open source per sostenere i suoi obiettivi strategici. La strategia dell'UE sull'open source, ad esempio, afferma che "l'open source è indipendente dalle aziende e dai Paesi" e sottolinea che l'open source ha un impatto sull'autonomia digitale dell'Europa. L'UE investe molto in iniziative come Next Generation Internet, Gaia-X o SovereignEdge che sviluppano o dipendono fortemente dalle tecnologie open source per ottenere la sovranità digitale ed evolvere le tecnologie internet essenziali. Non dovrebbe minare la sovranità digitale togliendo il tappeto da sotto i piedi alla sua stessa comunità open source.

Come supportare l’inziativa #FixTheCRA?

Gli obiettivi politici del CRA sono sostenuti da molte parti interessate e il problema non sta nei suoi obiettivi, ma nella forma in cui li si vogliono perseguire. Le preoccupazioni relative ai singoli obblighi imposti dal CRA possono essere affrontate attraverso la moderazione e il perfezionamento. Ad esempio, l'obbligo per i produttori di segnalare le vulnerabilità attivamente sfruttate (articolo 11 del CRA) alimenta il timore che si possa abusare di queste informazioni o che la divulgazione venga imposta prima che sia pronta una correzione. Tali preoccupazioni possono essere affrontate con processi che garantiscano la riservatezza e la riduzione dei problemi. Il timore che i fornitori di piattaforme di sviluppo possano diventare responsabili delle vulnerabilità del software che ospitano per conto di altri può essere affrontato attraverso un chiarimento (e di fatto viene affrontato, ad esempio, negli emendamenti proposti dal Consiglio dell'UE).

Per far funzionare il CRA è necessario affrontare due questioni importanti: 

• In primo luogo, le responsabilità e gli obblighi devono essere allineati alla struttura della catena di fornitura. Ogni produttore deve essere responsabile della sicurezza informatica dell'uso previsto del proprio prodotto, non di meno, ma nemmeno di più. I clienti che desiderano utilizzare un prodotto per un caso d'uso più complesso dovranno trovare un produttore disposto a supportarlo contrattualmente e a compensarlo. L'ultimo produttore che si frappone tra un consumatore e un prodotto digitale è l'azienda che prende decisioni sull'uso previsto, sulla capacità di supportare il prodotto per un periodo adeguato e sul software da inserire nel prodotto. È nella posizione migliore per decidere se l'open source è adatto allo scopo. È nella posizione migliore anche per pianificare il supporto del prodotto e gli aggiornamenti di sicurezza, collaborando con i loro partner contrattuali in una catena di fornitura e rivedendo le decisioni in qualsiasi punto della catena di fornitura sull'uso appropriato dell'open source.

• In secondo luogo, il rilascio di software open source non dovrebbe mai comportare obblighi nei confronti di utenti potenzialmente sconosciuti e anonimi. Al contrario, la CRA deve tornare alla nozione esplicita di entità commerciale che immette intenzionalmente un prodotto sul mercato e si assume le relative responsabilità. In questo modo si eliminerebbe la necessità di eccezioni poco chiare per la ricerca, i governi, la difesa e lo sviluppo open source "non commerciale", vincolando invece tutti gli attori commerciali a rispettare il CRA. In questo quadro, il rilascio di software open source in un progetto upstream non sarebbe considerato come la messa a disposizione di un prodotto sul mercato dell'UE, poiché non ha alcuna promessa di utilità e non c'è alcuna transazione nella catena di fornitura tra gli sviluppatori e gli utenti.

Affrontare questi due problemi di rottura con il CRA lo renderà più in linea con le relative normative dell'UE, come la Direttiva sulla Responsabilità sul Prodotto. Inoltre, risponderà a molte delle preoccupazioni sollevate dall'industria europea e dalle parti interessate della comunità open source.

La Linux Foundation Europe continuerà a sostenere l'UE nel miglioramento del CRA e della cyber resilienza nel mercato unico dell'UE in generale. Ci auguriamo che ci sia ancora la possibilità di contribuire a meglio direzionare questo atto legislativo. Chiediamo a tutte le parti interessate di impegnarsi nel processo e di farsi sentire. Ci appelliamo ai responsabili politici, evidenziando loro che nella sua forma attuale, il CRA potrebbe essere dannoso nei confronti delle imprese europe e renderle meno competitive. Per rimanere aggiornati sui recenti sviluppi del CRA o per sostenere l'impegno di Linux Foundation Europe, sottoscrivete il vostro impegno alla pagina web dedicata al Cyber Resilience Act.