La riforma della responsabilità del software in USA impensierisce le software house

Si parla ormai sempre più spesso della riforma della responsabilità del software, in particolare nel caso di prodotti che presentano insicurezze e vulnerabilità. I recenti commenti del direttore della Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti, Jen Easterly, hanno riportato l’attenzione sull’argomento e si tratta ancora di una questione spinosa. Questa riforma, che è uno dei capisaldi della neonata National Cybersecurity Strategy voluta dall’amministrazione Biden, prevede un nuovo sforzo per “riequilibrare” la responsabilità del rischio informatico, richiedendo ai fornitori di software di assumersi una maggiore responsabilità per la sicurezza dei loro prodotti.

L’amministrazione propone, in sintesi, di spostare la responsabilità sui produttori di software che non prendono ragionevoli precauzioni per rendere sicuri i loro prodotti, allontanandola dagli utenti finali che troppo spesso “sopportano le conseguenze di un software insicuro”. Per raggiungere questo obiettivo, l’amministrazione collaborerà con il Congresso e con il settore privato per creare un framework di “approdo sicuro” che protegga dalla responsabilità le aziende che sviluppano e mantengono i loro prodotti in modo sicuro. 

Non a caso, ogni volta che si parla di responsabilità rafforzata, i sostenitori in genere suggeriscono che un’azienda potrebbe ricevere protezione dalla responsabilità se “fa tutte le cose giuste”. Ma chi decide quali siano queste cose giuste? Il sospetto è che gran parte di esse sarà un’accozzaglia di tutte le caratteristiche e le pratiche di sicurezza possibili e immaginabili, anche quelle non specificamente rilevanti per un determinato prodotto.

Le normative sulla sicurezza favoriscono le grandi aziende

Le grandi aziende in genere prosperano grazie alle nuove normative: più sono onerose (tanto i “big” riescono a permettersele), meglio è. Dopotutto, un costo fisso di conformità diventa un fossato che protegge i loro mercati dai concorrenti più piccoli e con le spalle meno coperte. Pensiamo a quando, nel 2007, Mattel portò sul mercato bambole Barbie contenenti vernice al piombo. Se da un lato ciò comportò una multa multimilionaria al produttore americano, dall’altro diede l’impulso al Consumer Product Safety Improvement Act per rafforzare le normative (anche se Mattel aveva già violato quelle esistenti) e creare una maggiore autorità di controllo.

Quanto ha danneggiato Mattel tutto questo? Quasi nulla, visto che nei quattro anni successivi il prezzo delle sue azioni è quadruplicato. I piccoli operatori ebbero invece maggiori difficoltà a rispettare le nuove regole e i negozi di seconda mano spesso ritirarono dagli scaffali l’intero inventario di giocattoli per bambini perché non erano conformi alla nuova legislazione.

Va detto inoltre che alcune delle più importanti vulnerabilità di sicurezza dell’ultimo decennio non sono state colpa di una sola azienda. Heartbleed, Log4j, Shellshock e Meltdown hanno in comune il fatto che il codice vulnerabile si trovava in un software open-source. Se già le piccole aziende hanno difficoltà ad affrontare le normative governative, che dire di progetti come quelli open-source? Se dovessero essere costretti ad adottare qualsiasi best-practice di sicurezza possibile e immaginabile, avrebbero enormi difficoltà a continuare a operare. Il software open-source è fondamentale e se questi sviluppatori abbandonassero i loro progetti (o peggio, li cancellassero su consiglio dei consulenti), quanto staremmo peggio tutti noi?

La Casa Bianca sembra voler risolvere questo problema ritenendo responsabili non gli sviluppatori originali, ma solo l’assemblatore dei prodotti finali. Come implementare questo desiderio in una legge senza creare scappatoie abbastanza grandi da permettere ai team legali ben finanziati di far passare le loro aziende sarà, ovviamente, un esercizio per i lobbisti finanziati da queste aziende quando aiuteranno il Congresso a redigere una legge del genere.

La sicurezza è davvero un requisito del software?

Ovviamente, le aziende devono investire nella sicurezza dei prodotti, ma il come farlo è un altro discorso. Secondo Easterly le funzioni di sicurezza dovrebbero essere incluse di default e tutti i sistemi dovrebbero essere forniti con configurazioni sicure. Il governo, quindi, non permetterà più di acquistare nulla che non sia l’implementazione più sicura. Dal punto di vista funzionale, si tratta di una tassa che dovremo pagare noi in quanto acquirenti, sia per quello che riguarda il prezzo (tutte le funzionalità di sicurezza da implementare nel prodotto hanno un costo), sia per quanto riguarda l’usabilità, visto che molte funzionalità di sicurezza, nella loro impostazione più rigida, rendono il prodotto sottostante difficile, se non del tutto impossibile da usare.

E non finisce qui. Pensate ad esempio ai servizi cloud complessi che coinvolgono più aziende. Di chi è la colpa quando ogni sistema funziona come pubblicizzato, ma combinandosi con un altro sistema dà luogo a risultati spiacevoli? Cosa succede quando un consumatore utilizza una tecnologia in un modo non previsto? E cosa succede quando vengono scoperti nuovi tipi di vulnerabilità che rendono “vulnerabile” un intero settore?

A ogni obiezione del genere si può ovviamente replicare con regole sempre più dettagliate e circostanziate in grado di coprire la maggior parte dei casi, ma l’elenco dei problemi è abbastanza lungo da non rendere necessaria una nuova modifica generale della legge sulla responsabilità. Come abbiamo appena visto, le conseguenze potrebbero infatti essere molto negative per tutti noi.