Open source e Cyber Resilience Act: gestire le responsabilità

Chi risponde legalmente della vulnerabilità di una libreria scaricata da un repository pubblico, mantenuta gratuitamente da un contributore volontario, quando quella libreria finisce nel cuore di un prodotto commerciale marcato CE? Con il Cyber Resilience Act questa domanda smette di essere teorica e diventa un problema di gestione del rischio per ogni CTO europeo.

Le tecnologie open source sono utilizzate dal 90% delle organizzazioni a livello mondiale, secondo la Linux Foundation¹. Non si tratta di un dettaglio marginale: uno studio della stessa Linux Foundation del 2022 stima che il 70-90% di qualsiasi codebase moderna sia composto da componenti free e open source.² In modo simile, il report Synopsys 2024 indica che il 96% delle codebase commerciali contiene open source software ed il 77% di tutto il codice di quelle stesse codebase esaminate originava da codice open source.³

In altre parole: il software che le aziende vendono, in larga parte, non lo hanno scritto loro.

Qui nasce la tensione centrale del Cyber Resilience Act (CRA): il regolamento europeo introduce responsabilità legali su prodotti costruiti in gran parte su componenti che, formalmente, nessuno “possiede”. Quando integri decine di librerie in un prodotto commerciale, di chi è la responsabilità della vulnerabilità? La risposta non è più ovvia.

In questo articolo chiariamo cosa cambia per chi usa e contribuisce all’open source, quali rischi ricadono concretamente sull’azienda e come strutturare una governance della supply chain software conforme al CRA, senza smettere di beneficiare del vantaggio competitivo che il codice aperto garantisce.

Cosa si intende per open source e il software è davvero gratuito?

L’open source è software il cui codice sorgente è pubblicamente accessibile, modificabile e ridistribuibile secondo licenze approvate dalla Open Source Initiative (OSI). Ma accessibilità gratuita del codice non significa costo zero: il costo si sposta su integrazione, manutenzione, sicurezza e conformità. Chi confonde “libero” con “gratuito” sottostima proprio le voci che il CRA ora rende obbligatorie.

La distinzione tra i termini conta più di quanto sembri. Il software libero, nell’accezione della Free Software Foundation (FSF) fondata da Richard Stallman, mette al centro le libertà dell’utente e adotta licenze copyleft come la GNU General Public License (GPL), che obbliga a ridistribuire le opere derivate alle stesse condizioni. L’open source, promosso dalla OSI, ammette anche licenze più permissive orientate all’adozione commerciale. Il software proprietario chiude invece il codice e trasferisce al vendor la responsabilità operativa, al prezzo del vendor lock-in.

La pervasività dell’open source nelle aziende è concreta e quotidiana, ben oltre gli ambienti tecnici:

• Sistemi ERP e CRM open source che gestiscono processi core aziendali (con soluzioni come Odoo o Dolibarr ERP CRM che sfidano i vendor tradizionali).

• Applicazioni intranet open source per la collaborazione interna e la gestione documentale.

• Software di auditing informatico open source per il monitoraggio continuo della sicurezza e la compliance.

• Suite di office applications alternative alle piattaforme proprietarie, come gli storici Apache OpenOffice e LibreOffice, o il nuovo Euro-Office lanciato a giugno 2026.

• Software open source per la gestione finanziaria (ad esempio Money Manager Ex) e piattaforme e-commerce flessibili.

Sotto questa superficie applicativa opera un’infrastruttura interamente aperta: Linux come sistema operativo dei server, Kubernetes per l’orchestrazione dei container sotto l’egida della Cloud Native Computing Foundation, Apache Kafka per lo streaming dei dati, Ansible per l’automazione. La visione dell’open source come bene pubblico e leva di sovranità, che in SparkFabrik consideriamo il fondamento del nostro sviluppo software, nasce proprio dal riconoscere che questo strato invisibile regge l’intera economia digitale.

Open source, software libero o proprietario: la tabella di confronto

La lettura strategica è netta: l’open source riduce il vendor lock-in ma redistribuisce la responsabilità operativa e di sicurezza sull’utilizzatore. È esattamente questo spostamento che il CRA formalizza sul piano giuridico.

Come il Cyber Resilience Act ridistribuisce le responsabilità sull’open source

Il CRA introduce la figura dell’open source steward e trasferisce gli obblighi di sicurezza su chi immette prodotti sul mercato, non su chi sviluppa codice in modo collaborativo. Ma la formulazione originale del regolamento non tracciava questa linea con chiarezza, rischiando di coinvolgere anche i contributori upstream in responsabilità che non potevano ragionevolmente sostenere.

Il nodo giuridico è stato illustrato con efficacia da Mirko Boehm della Linux Foundation Europe: il CRA, nella sua prima versione, non distingueva tra lo sviluppo collaborativo a monte e l’immissione di un prodotto sul mercato, e non limitava la responsabilità all’uso previsto. Un contributore volontario avrebbe potuto rispondere di vulnerabilità anche in scenari d’uso del tutto imprevisti, come nel caso paradossale di un frammento di codice che finisse per controllare una centrale nucleare. È il tipo di rischio che ha allarmato l’intera community, un dibattito che abbiamo ricostruito analizzando le preoccupazioni del mondo open source.

Perché le fondazioni non possono semplicemente assorbire questi obblighi? Per una ragione economica ben documentata. Molti progetti open source non ricevono alcun finanziamento e, anche distribuendo equamente i fondi disponibili su tutti i progetti, si arriverebbe a poco più di 250.000 dollari ciascuno: una cifra che basta forse a pagare un community manager e a organizzare qualche meetup, non certo a mantenere personale di sicurezza a tempo pieno.⁴ Inoltre, come chiarisce la Linux Foundation Europe, quei fondi arrivano inoltre vincolati a progetti specifici dai donatori (donor-directed funds), al punto che nemmeno la fondazione stessa potrebbe dirottarli per risolvere i problemi di sicurezza di un altro progetto; e le altre fondazioni open source dispongono spesso di risorse ancora più limitate.

Caricare i maintainer open source degli obblighi di security-by-design del CRA⁵, in una fase in cui la sostenibilità di lungo termine di molti progetti è già messa in discussione dagli stessi contributori, rischia di rivelarsi controproducente.

La risposta è stata l’iniziativa #FixTheCRA, coordinata da Linux Foundation Europe su cinque fronti: proposta di emendamenti tramite Open Forum Europe, divulgazione delle criticità, una lettera aperta firmata da una coalizione di fondazioni open source, tavole rotonde con le istituzioni europee (con panel a KubeCon Europe e all’Open Source Summit) e la creazione di sedi di collaborazione permanenti. SparkFabrik partecipa a questo ecosistema come membro di Linux Foundation Europe e di OpenSSF⁶, e il nostro CTO Paolo Mainardi siede nell’Advisory Board di LF Europe.

Chi risponde delle vulnerabilità: upstream, steward o produttore?

Il CRA distingue tre ruoli con responsabilità diverse:

• Contributore upstream: sviluppa codice in modo collaborativo, fuori da logiche commerciali. È escluso dagli obblighi diretti del regolamento.

• Open source steward: figura nuova introdotta dal CRA, con obblighi ridotti e proporzionati (tipicamente fondazioni e organizzazioni che sostengono progetti).

• Produttore commerciale: chi immette il prodotto sul mercato con la marcatura CE. Si assume la piena responsabilità legale della sicurezza.

Il takeaway per il decision maker è diretto: se la tua azienda integra open source in un prodotto commerciale, la responsabilità legale ricade su di te, non sul progetto upstream. La marcatura CE certifica che sei tu a garantire la conformità dell’intero stack, dipendenze incluse.

Quali rischi corrono le aziende europee che costruiscono sull’open source?

I rischi principali sono tre: l’aumento dei costi di conformità a carico soprattutto delle PMI, il possibile ritiro di software dal mercato UE da parte delle community e l’impatto su iniziative europee di sovranità digitale. Sono rischi che colpiscono in modo asimmetrico proprio chi usa l’open source per competere.

Analizzati per livello, i rischi si articolano così:

• Rischio economico: il CRA potrebbe imporre costi aggiuntivi sull’uso e sui contributi open source principalmente a carico delle imprese europee, penalizzando le PMI che sull’innovazione aperta fondano la propria capacità di competere con i grandi operatori storici.

• Rischio di continuità della supply chain: le community potrebbero rifiutarsi di rendere disponibile software nell’UE, lasciando la distribuzione a intermediari commerciali extra-UE, con impatto su Gaia-X⁷, SovereignEdge⁸, e Next Generation Internet⁹.

• Rischio strategico: le classi di prodotti critici del CRA coincidono con le tecnologie open source fondamentali.

Questo terzo punto merita attenzione, perché contiene un paradosso. La Classe II del CRA, soggetta a requisiti di sicurezza tra i più severi, include sistemi operativi per server, hypervisor e runtime dei container: esattamente le tecnologie aperte che reggono l’infrastruttura cloud europea. Abbiamo approfondito questa tensione tra normativa e competitività nell’analisi su come il CRA incide sull’autonomia strategica dell’Unione.

Il paradosso si acuisce sul fronte del cloud sovrano. Offerte come AWS European Sovereign Cloud, Google S3NS e il progetto Bleu si presentano come europee, ma restano architetturalmente controllate da hyperscaler non europei¹⁰. In questo quadro l’open source, e non l’etichetta “sovrano” apposta su tecnologie proprietarie, resta la leva reale di indipendenza tecnologica per le organizzazioni del continente. Per un CTO europeo, questo significa privilegiare stack basati su tecnologie open source verificabili nella propria strategia di procurement cloud.

Come gestire le responsabilità open source in modo conforme al CRA

Gestire le responsabilità significa passare dal consumo passivo dell’open source a una governance strutturata: inventario delle dipendenze, security-by-design, contributo attivo ai progetti e trasparenza documentale verso il mercato. Non è un adempimento burocratico, ma un cambiamento nel modo in cui l’azienda concepisce la propria supply chain software.

Il primo pilastro è la governance della supply chain. Serve visibilità totale sulle dipendenze, incluse quelle transitive che nessuno ha selezionato consapevolmente. Su questo terreno la nostra esperienza è diretta: SparkFabrik è maintainer di DruBOM, un modulo Drupal che integra Anchore Syft per generare la Software Bill of Materials completa di un’installazione, dipendenze PHP e JavaScript comprese. È lo stesso approccio che abbiamo descritto parlando di come mappare i rischi delle dipendenze per la marcatura CE.

Il secondo pilastro è metodologico. Uno sviluppo software conforme al CRA richiede controlli di sicurezza integrati fin dalle prime fasi, non aggiunti a posteriori. In SparkFabrik pratichiamo un principio di security enablement over enforcement: la sicurezza non è un gate imposto a valle dai team di compliance, ma una capacità messa nelle mani degli sviluppatori, che diventano attori consapevoli della postura di sicurezza del prodotto.

Il terzo pilastro è culturale: passare da utilizzatori a contributori. Sachiko Muto, nel contesto di Drupal4GovEU, ha sostenuto che le istituzioni devono partecipare ai progetti aperti contribuendo con i propri sviluppatori, non solo finanziandoli¹¹. È la stessa filosofia sintetizzata da Paolo Mainardi, CTO di SparkFabrik¹²:

“Open Source is a public good that must be supported and funded in a new, modern way: like public infrastructure”.

Contribuire attivamente riduce il rischio strategico e rafforza la sostenibilità dei progetti da cui l’azienda dipende.

In termini operativi, il percorso ad alto livello si articola in cinque passi:

1. Mappare tutte le dipendenze, dirette e transitive, con strumenti di analisi composizionale.
2. Classificare i prodotti per classe di rischio secondo il perimetro del CRA.
3. Integrare i controlli di sicurezza nel ciclo di sviluppo, in ottica DevSecOps.
4. Definire policy di aggiornamento e disclosure delle vulnerabilità.
5. Contribuire upstream ai progetti critici per la propria attività.

Vale la pena notare che l’apertura non riguarda solo l’infrastruttura tradizionale, ma si estende al duplice rapporto tra open source e intelligenza artificiale. Da un lato, l’AI permette di gestire progetti aperti su una scala senza precedenti, consentendo a un singolo sviluppatore di raggiungere in poco tempo la produttività di un intero team; dall’altro, l’open source accelera il progresso stesso dell’AI attraverso modelli e framework condivisi. Il 72% degli sviluppatori, secondo il sondaggio Stack Overflow 2024, dichiara una posizione favorevole all’uso di strumenti AI nel proprio workflow¹³. Integrare questi nuovi componenti generativi nei propri prodotti commerciali significa ereditare ulteriori dipendenze: la governance che costruisci oggi dovrà reggere anche questa complessità, garantendo che l’adozione dell’AI rispetti i medesimi obblighi di tracciabilità e sicurezza imposti dal CRA.

Dalla dipendenza passiva alla governance dell’open source

Il CRA non è una minaccia all’open source, ma un acceleratore verso una gestione matura delle responsabilità della supply chain software. Il regolamento formalizza sul piano legale una verità che i team tecnici conoscono da tempo: chi vende un prodotto ne risponde interamente, comprese le parti che ha ereditato dal codice aperto.

Le aziende che strutturano oggi una governance dell’open source, con inventario delle dipendenze, sicurezza integrata by design e contributo attivo ai progetti da cui dipendono, trasformano un obbligo normativo in vantaggio competitivo e in leva concreta di sovranità digitale. È la differenza tra subire la conformità e usarla come acceleratore di qualità.

Nel prossimo articolo della serie affronteremo come gestire la complessità di Software Bill of Materials multiple in progetti grandi e multi-servizio, tra i formati SPDX e CycloneDX e l’automazione delle dipendenze transitive.

Se vuoi valutare la maturità della tua supply chain open source e pianificare l’adeguamento normativo, il nostro percorso di supporto sul Cyber Resilience Act mette a disposizione l’esperienza di un team KCSP, membro CNCF, Linux Foundation Europe e OpenSSF. Contattaci e parlaci delle tue sfide. 

Note e fonti