Categories
governance open source php social sustainability tecnologia

Cyber Resilience Act e Sostenibilità Sociale del Software

Le buone intenzioni del CRA di regolamentare la sicurezza delle infrastrutture digitali sono state implementate con il principio di usare la dinamite per andare a pesca. In un barile. Posizionato nel nostro bagno. Sopra la tazza del cesso. Sicuramente qualche pesce lo faremo fuori, ma nel processo sarà tanta la m…a da dover spalare. :(

Non presumere mai cattiveria laddove basti la stupidità.

Rasoio di Hanlon

Il Rasoio di Hanlon è la prima cosa che mi viene in mente quanto leggo documenti come il Cyber Resilience Act o il decreto legge antipirateria.

Questo perché nonostante le buone intenzioni dietro a tali bozze di leggi (o peggio, leggi approvate) spesso è evidente la carenza di una competenza tecnica chiara ma, soprattutto, l’incapacità di avere una visione complessiva del tema sul fronte implementativo, sociale ed economico.

Se per la legge anti pirateria ci si può appellare alla definizione di blocco degli IP solo se univocamente destinati ad attività illecite (art. 2.1) per trovare una scappatoria utile a liberare tutti i server dietro ad una CDN (voglio però vedere gli impatti, economici e sociali, sulle imprese quando verrà bloccato un ecommerce che fattura qualche milione di euro o il server di un ospedale per qualche giorno, perché la macchina burocratica sarà complessa da gestire) per il Cyber Resilience Act (CRA d’ora in poi) il problema è ben più profondo.

Il Cyber Resilience Act è una proposta di legge dell’Unione Europea che punta a definire le disposizioni urgenti in materia di cyber sicurezza.

Il CRA dovrebbe avere l’obiettivo di garantire che i prodotti digitali immessi sul mercato dell’UE presentino meno vulnerabilità e i produttori siano responsabili della sicurezza informatica per tutto il ciclo di vita di un prodotto. Fin qui tutto, più o meno, bene (se parlassimo di prodotti puramente commerciali e che al loro interno non dipendono da prodotti puramente community driven), peccato che il modo in cui i requisiti fondamentali per garantire questa sicurezza siano stati definiti in modo vago e potenzialmente dannoso per l’ecosistema Open Source e, forse, per tutto l’ecosistema digitale europeo.

Ma andiamo per gradi.

I requisiti fondamentali del Cyber Resilience Act sono:

  • la definizione di un sistema di certificazione per i prodotti connessi;
  • l’obbligo per i produttori di segnalare eventuali vulnerabilità dei propri prodotti;
  • l’obbligo per i produttori di fornire aggiornamenti software per correggere eventuali vulnerabilità e di non divulgare prodotti non completi;
  • l’obbligo per i produttori di fornire informazioni chiare e comprensibili sulla sicurezza dei propri prodotti.

Purtroppo però secondo la comunità OSS, il linguaggio utilizzato dal CRA non rende chiara la responsabilità legale per un prodotto community driven (ad esempio Python), dando potenzialmente alla Python Software Foundation (PSF) la responsabilità finanziaria per qualsiasi prodotto scritto con quello stesso linguaggio. Se la PSF venisse ritenuta responsabile, il potenziale onere finanziario potrebbe rendere impossibile fornire Python, PyPI e molti strumenti AI strategici al pubblico europeo (vista anche l’importanza di quest’ultima per l’AI Act europeo).

Ma non parliamo solo di linguaggi, anche prodotti OSS già sul mercato e distribuiti da fondazioni o entità senza scopo di lucro avranno i loro grattacapi. La lettera aperta indirizzata ai legislatori dell’UE e scritta dai principali CMS PHP Open Source (Drupal, Typo3, WordPress, Joomla) sottolinea l’importanza del software libero e open source per l’economia delle SME e dei singoli nel settore dell’informatica e chiede di rivedere il Cyber Resilience Act andando ad identificare alcuni punti cardine per cui adottare l’attuale testo sarebbe dannoso:

  • non distingue tra software proprietario e software open source;
  • non fornisce una definizione chiara di “produttore” e “fornitore”;
  • non fornisce una definizione chiara di “prodotto”;
  • non fornisce una definizione chiara di “vulnerabilità”;
  • non fornisce una definizione chiara di “rischio”.
  • non scinde la reponsabilità di chi offre “supporto” (gratuito o a pagamento) da quella di chi produce (o vende) il prodotto

Questo senza andare a discutere di particolari aspetti come il divieto di diffondere software in versione alfa, o comunque non definitiva, dimostrando quanto il mondo dei legislatori sia totalmente distaccato e lontano da quelle che sono le pratiche del mondo OSS.

In sostanza sembra che il CRA sia stato scritto, se non fosse che credo nel succitato rasoio di Hanlon, per favorire le grandi multinazionali del software, che, ricordiamoci, sono prevalentemente americane, andando a minare ogni forma di imprenditoria digitale locale, appesantendola di inutile burocrazia e costi di gestione non assorbibili dai più.

Questo porterà ad un impoverimento del settore, che già oggi non gode dei fondi a pioggia d’oltre manica e che è prevalentemente portato avanti da piccole imprese; il tutto rischiando di creare una crisi di mercato ed una svendita delle imprese (con ricadute su temi di sostenibilità sociale) all’estero. Il tutto esponendoci anche a rischi geopolitici (quindi sostenibilità di governance) non indifferenti dovendo, per forza affidarci a prodotti americani o cinesi gestiti da colossi su cui, la storia ci insegna, ben poco i nostri legislatori possono operare.

Le buone intenzioni di regolamentare un minimo la sicurezza delle infrastrutture digitali sono state implementate con il principio di usare la dinamite per andare a pesca. In un barile. Posizionato nel nostro bagno. Sopra la tazza del cesso.

Sicuramente qualche pesce lo faremo fuori, ma nel processo sarà tanta la m…a da dover spalare. :(

Divulgate le lettere aperte su questi temi e coinvolgete le associazioni di settore, dando loro l’occasione di dimostrare di non essere stupide o in malafede.