L’approccio del Cyber-Resilience Act dell’Unione Europea all’open source deve essere riconsiderato

L’approccio del Cyber-Resilience Act dell’Unione Europea all’open source deve essere riconsiderato

A cura di Alois Reitbauer, Chief Technology Strategist, Dynatrace

Il progetto di legge sul Cyber-Resilience Act (CRA) dell’Unione Europea, approvato dai parlamentari europei a luglio, intende ridurre il rischio per i cittadini europei di subire violazioni dei dati e attacchi dannosi ai propri dispositivi. Il CRA mira a raggiungere questo obiettivo imponendo le migliori pratiche di sicurezza in tutta l’industria tecnologica europea. A tal fine, imporrà standard minimi di sicurezza per i prodotti tecnologici venduti all’utente finale nella UE, come i dispositivi IoT, i computer desktop e gli smartphone.

TI PIACE QUESTO ARTICOLO?

Iscriviti alla nostra newsletter per essere sempre aggiornato.

Per raggiungere i suoi obiettivi, il CRA deve applicare questi standard anche al software e all’hardware che costituiscono la catena di fornitura dei prodotti per gli utenti finali. Tuttavia, oltre alle soluzioni commerciali all’interno della supply chain del software, il CRA sta cercando di applicare questi rigorosi standard di sicurezza a progetti e comunità open source non commerciali. Questo potrebbe mettere decine di migliaia di volontari a rischio di azioni legali e danneggiare in modo significativo il settore tecnologico del continente. I legislatori che stanno dietro al CRA devono rivedere urgentemente il modo in cui considerano il software open source.

Perché il CRA pone problemi all’open source

Il CRA punta a imporre alle organizzazioni obblighi legali per garantire che i prodotti e i servizi che vendono al pubblico siano sufficientemente sicuri. Questo richiede che le organizzazioni garantiscano che i loro prodotti soddisfino standard prestabiliti per quanto riguarda la reportistica, la documentazione, le valutazioni dei rischi e le patch di sicurezza e il monitoraggio successivi al rilascio. Le organizzazioni che non rispettano questi standard rischiano di essere responsabili di incidenti di sicurezza e di incorrere in sanzioni pecuniarie per la mancata conformità.

Leggi anche:  Sicurezza informatica, diritto d'autore: studio legale D'Agostini di Udine, ai vertici in Italia per casi vinti in giudizio e consulenze alle aziende

Per funzionare nella pratica, il CRA deve estendere questo regime anche alla catena di fornitura del software – i vendor e gli sviluppatori che distribuiscono il software riutilizzato nei prodotti degli utenti finali. Tutto il software che viene distribuito nell’UE deve essere autocertificato dagli sviluppatori come sicuro secondo gli standard del CRA. È qui che sorge il problema principale, poiché gran parte della catena di fornitura del software è costituita da software open source (OSS). Si ritiene infatti che fino al 97% di tutte le applicazioni includa codice OSS. Allo stato attuale del CRA, le comunità che gestiscono progetti OSS devono applicare al loro lavoro gli stessi standard di sicurezza delle aziende che vendono soluzioni commerciali. E, cosa preoccupante, potrebbero essere legalmente responsabili per qualsiasi incidente di sicurezza a valle che si verifichi a causa di problemi con il loro codice.

Le comunità Open Source non sono commerciali e nascono da contributi volontari, quindi poche hanno le risorse per garantire che il loro codice sia idoneo a essere autocertificato secondo il CRA. Ciò comporta il rischio che i contributori e le comunità OSS europee cessino di operare o siano soggetti ad azioni legali che non hanno le risorse finanziarie per affrontare. Poiché il software OSS è il motore dell’industria tecnologica in generale, grazie al suo uso onnipresente, questo potrebbe infliggere un duro colpo all’intero ecosistema tecnologico europeo.

Come rendere il CRA compatibile con l’Open Source

L’obiettivo del CRA è ammirevole: garantire la sicurezza di base del software e dei dispositivi con cui interagiamo quotidianamente. È ancora possibile raggiungere questo obiettivo garantendo al contempo che i progetti e le comunità OSS possano continuare a innovare.

Leggi anche:  Anatomia di un attacco phishing

La fonte del problema è che, nella sua attuale bozza, il CRA tratta l’OSS come se fosse intercambiabile con le alternative commerciali. Questo non riflette la realtà sul campo: l’OSS, libero di essere utilizzato, è raramente offerto come una soluzione completa. È semplicemente un elemento o un componente di un’offerta più ampia. Il CRA dovrebbe quindi trattare il codice OSS come un bene pubblico, come l’aria pulita o le bande radio.

Invece di controllare i progetti e le comunità OSS, il CRA dovrebbe attribuire la responsabilità della sicurezza ai soggetti commerciali che utilizzano questo codice nei prodotti e nei servizi che forniscono ai loro clienti. In questo modo, le entità commerciali hanno la responsabilità di garantire la comprensione dei rischi e di rafforzare la sicurezza dei prodotti che rilasciano. A tal fine, le organizzazioni devono dimostrare di possedere tre capacità fondamentaliper mantenere sicuri i propri componenti OSS:

  1. Analisi delle vulnerabilità a runtime – Monitoraggio continuo per rilevare eventuali vulnerabilità in un prodotto e nei suoi componenti non appena vengono introdotte, sia nel codice personalizzato che in quello open source. I team di sicurezza e di sviluppo devono essere in grado di comprendere immediatamente l’impatto potenziale di qualsiasi vulnerabilità rilevata e di avere la visione necessaria per risolverla rapidamente, prima che l’integrità delle applicazioni e dei dati sia compromessa.
  2. Hardening delle applicazioni: verifica dei prodotti per l’esposizione alle principali minacce alla sicurezza che mirano alle vulnerabilità critiche, come le command e SQL injection, utilizzando elenchi di minacce di riferimento nel settore, come l’Open Worldwide Application Security Project (OWASP). Le organizzazioni devono inoltre essere in grado di rilevare l’esecuzione di questi attacchi e bloccarli prima che possano causare danni.
  3. Automazione della sicurezza – Stabilire flussi di lavoro automatizzati per rilevare, rimediare e risolvere incidenti o vulnerabilità di sicurezza, nei componenti OSS e non solo. Questo contribuisce ad accelerare i tempi di risoluzione e a ridurre l’esposizione di prodotti e servizi a vulnerabilità critiche.
Leggi anche:  Kaspersky analizza l’evoluzione di Mallox, da private malware a Ransomware-as-a-Service

Come il CRA potrebbe mettere il turbo all’open source europeo

Se questi standard venissero inclusi nel CRA, l’atto potrebbe in definitiva diventare un vantaggio significativo per lo sviluppo dell’Open Source. Anziché scoraggiare la partecipazione all’OSS, l’applicazione del CRA all’uso responsabile dell’OSS potrebbe spingere le organizzazioni a investire nella mappatura, nel riconoscimento e nella protezione dei componenti OSS che utilizzano nei loro prodotti.

Questo aumento degli investimenti commerciali si ripercuoterebbe inevitabilmente sul più ampio ecosistema OSS e, in ultima analisi, significherebbe maggiori risorse complessive dedicate alla manutenzione e all’aggiornamento dei progetti. I benefici di questa situazione potrebbero essere enormi, aumentando drasticamente il ritmo dell’innovazione del software in tutta l’UE. Soprattutto, questi requisiti garantirebbero un ecosistema OSS più sicuro in Europa e non solo. Ciò significa una migliore realizzazione dell’obiettivo primario del CRA: prodotti e servizi tecnologici più sicuri per i cittadini europei.