Per anni è mancata una normativa che consentisse di applicare in termini concreti e funzionali il riuso. Ma da maggio 2019 ci sono le nuove linee guida per l’art. 69 del Codice dell’Amministrazione digitale sul riuso. Regole più semplici e chiare, che suscitano una riflessione: lo Stato siamo noi tutti cittadini, quindi un applicativo sviluppato per la pubblica amministrazione non solo deve avere una licenza open source, ma deve essere messo a disposizione in un repository pubblico affinché tutti lo possano usare e migliorare a loro volta. Approfondiamo il tema.
Gli obiettivi del riuso
Il concetto alla base del riuso è: se lo Stato paga per scrivere un’applicazione software, un’altra amministrazione dovrebbe poter usufruire di quell’investimento, utilizzando a sua volta, in tutto o in parte, l’applicativo che, essendo stato sviluppato con soldi pubblici, appartiene allo Stato. Le licenze open source sono licenze diffuse, da moltissimi anni, attraverso le quali è fiorita l’economia del software, ad esempio, tramite GNU/Linux che trovate sul 75% dei cellulari nella forma rivista di Android, o in cloud come sistema operativo dei server, venduto[1] come servizio in affitto, un po’ da chiunque, da Google a Microsoft, passando per Aruba, Seeweb ad Amazon Web Service. Ci sono poi applicativi e linguaggi da Mysql a Postgres, da Mono a Java, da Wordpress a Magento che trovate ovunque: avete Sky Q a casa? Una smart TV? Una lavatrice di ultima generazione? Un termostato che manovrate via app? Quasi tutto è basato su software open source.
Nello specifico una licenza open source garantisce a chi la applica dei principi: posso leggere il codice sorgente, lo posso studiare, lo posso modificare, lo posso usare per qualunque scopo, lo posso ridistribuire. La presenza di questa normativa, oggi, evita le discussioni abbastanza sterili (per non dire stupide) del passato, secondo le quali, pubblicare un programma sviluppato ad hoc, con i soldi di una PA per la PA, in modo che terzi estranei lo potessero sfruttare, avrebbe addirittura causato un danno economico alla PA stessa o problemi di sicurezza. È facile argomentare che sia l’esatto contrario.
Qualità del software
Oggi questa regolamentazione chiara ed efficace non avrà un impatto immediato, poiché, è pur sempre materia complessa e nuova per molte PA, con abitudini passate ben diverse: si parla di licenze, di software e di rendere pubblico un applicativo. Gli allegati al regolamento consentono però di affrontare questi problemi uno alla volta, con un supporto concreto. Quali sono i vantaggi del software libero? Il tema della sicurezza è sempre stato un tema controverso per molti; dopotutto, se, fino a ieri, scrivevo software per un ministero e domani fornirò ancora software al medesimo ministero, perché la qualità di ciò che scrivo dovrebbe cambiare? Cambierà solo perché il software sarà reso pubblico con una licenza open source? La risposta è “probabilmente sì”. Terzi potranno verificare ciò che ho scritto ed, eventualmente, proporre modifiche per supportarmi o per altre attività, nel primo caso, migliorando il progetto e nel secondo, magari, per “forkarlo”, cioè, usarlo per creare un nuovo progetto con scopi differenti. Questo pone, ovviamente, sfide diverse a chi il software lo scrive, perché lo stesso si troverà con più persone che potrebbero controllare la qualità del lavoro svolto.
Nel mondo open source è noto anche lo “shaming effect”: dovendo pubblicare il sorgente e dunque sottoporlo al giudizio critico di altri sviluppatori, uno sviluppatore tenderà a documentare meglio il proprio codice, a giustificare la ragione per certe scelte ed evitare “scorciatoie” e comportamenti notoriamente proni alle insicurezze o ai malfunzionamenti. La qualità del software finisce con l’avere un impatto con i temi della sicurezza: che ne sa un Ministero se il software che usa al suo interno contiene backdoor o problemi che causano frequente manutenzione, magari inseriti volontariamente? Probabilmente ha il sorgente, ma non ha nessuno che lo verifichi né un incentivo a farlo, perché questo non è previsto dalla legge; capita spesso che ci si limiti a fare quello che è previsto dalla legge, e non quello che sarebbe opportuno fare. È poi del tutto stupido e smentito da qualsiasi teoria sulla sicurezza del software il fatto che pubblicare il codice sorgente o le specifiche del software o di un servizio informatico siano causa di insicurezza; al contrario, proprio l’esposizione di tali elementi contribuisce ad aumentare le probabilità che le insicurezze più ovvie siano evitate e a ogni modo la “security through obscurity” (la sicurezza attraverso la non trasparenza) è da ritenuta da qualsiasi esperto un falso tipo di sicurezza.
Come ben sanno tutti gli sviluppatori, un software senza bug non esiste. Da qui a dire che siano inevitabili ne passa! Ogni sforzo che consenta di migliorare la qualità del software è uno sforzo che migliora la sicurezza e può avere un impatto sulla cybersecurity, fattore rilevante quanto di parla di servizi online nella PA. Pubblicare il software consente a più persone di verificarlo, potenzialmente migliorarlo e, quindi, mitigare i rischi di bug o scoprire atti di volontario sabotaggio. Giusto in questi giorni una persona è stata arrestata in Pennsylvania per avere sabotato un programma al solo scopo di garantirsene la manutenzione: lo ha fatto per due anni di fila, dal 2014 al 2016, causando danni ad una multinazionale.
Giustizia digitale e software pubblico
Che succede se il software della PA serve per firmare sentenze? Se avesse un bug le sentenze potrebbero avere un serio problema di validazione quali documenti informatici! E che succederebbe se il software determinasse esso stesso (e non un provvedimento amministrativo motivato e soggetto alla giurisdizione del TAR) la natura delle specifiche tecniche di un servizio pubblico? Succederebbe che si rischierebbe un accesso limitato per alcuni operatori del settore. Nei casi appena citati il riuso, attraverso il rilascio del software con licenza open source, avrebbe risultati molto positivi.
Non dimentichiamoci che la resilienza di un servizio e gli aspetti di cyber security, oggi, sono fattori estremamente importanti, perché, la PA è piena di infrastrutture digitali necessarie per erogare servizi ai cittadini. Su questa materia specifica, ho aperto la sottoscrizione di una petizione molto simile alla petizione del 2007. Se il codice sorgente è pubblicato in licenza open source, allora possiamo misurarne la qualità e verificarne i costi (accedendo al codice è più facile misurare in maniera precisa le funzionalità e dunque applicare metriche standard di valutazione), ma, anche valutarne la sicurezza.
Voto elettronico
Non succederà tutto subito, non accadrà oggi, non accadrà domani, e sarà un processo per fasi, ma, ci sono ambiti in cui è facilmente intuibile il valore immenso della sicurezza e del riuso del software nella PA: il voto elettronico. Posto che unanimemente il voto politico elettronico ‒ il quale deve contemporaneamente garantire segretezza, libertà, verificabilità, genuinità del voto ‒ è considerato un problema irrisolvibile e chi lo propone un venditore di fumo, in generale come possiamo fidarci che il software su cui si basa faccia quello che il suo sviluppatore dice che fa? Devo fidarmi di un terzo, senza poter sapere cosa ha scritto, se il software ha una backdoor, se ha commesso errori che espongono il software a possibili insicurezze o manipolazioni esterne? È un problema di autorevolezza ed autorità di chi propone la soluzione, che si risolve fidandosi ciecamente di un terzo, o il sorgente e la licenza hanno un impatto sulla fiducia?
Una misura della sicurezza, l’efficace assunzione di strumenti, procedure e controlli possono dare delle garanzie, ma, certamente sono maggiori se il software è open source e il fornitore lo consegna in quanto codice, ed è la PA stessa ad effettuare in modo pubblico e verificabile la build, ossia il processo di trasformazione da codice sorgente a codice macchina; elemento minimo (ma non sufficiente) per cautelarsi su cosa fa davvero il software.
Aspetti di cyber security
Prendo spunto in materia di cyber security dal framework OWASP Test 4.0 (project leader Matteo Meucci e Andrew Muller ed autori vari, in licenza “Creative Commons (CC) Attribution Share-Alike”) . Traduco e sintetizzo liberamente l’analisi dal testo originale: “Il penetration testing è molto efficace come strumento di verifica della sicurezza delle reti, ma per le applicazioni web il tema è diverso: serve un approccio bilanciato ed è necessario che il software sia testato sin dalle prime fasi”.
Questi fattori in sé non si legano immediatamente al riuso e rilascio in licenza open source, ma, tra i test da effettuare per avere un approccio bilanciato, che non si affidi al mero penetration testing (“pen-testing”), c’è la revisione del codice sorgente: capite bene che se leggendo il codice sorgente di un programma ci trovo le credenziali dell’utente di amministrazione con nome e password, c’è un problema e il problema non si risolve nascondendo il codice (“security through obscurity”), ma analizzandolo sin dalle prime fasi. La PA non è certo attrezzata oggi per una attività di verifica del codice sorgente dei propri applicativi, ma questo non significa che non sia necessario e, certamente, pubblicare il codice sorgente in licenza open source consente una revisione anche da parte di terzi: il codice così ottenuto è più sicuro.
I test per i software
Per gli applicativi software servono verifiche: test di regressione, test di integrazione, test di accettazione, test unitari e di sistema. Questi test sono altro software che, pubblicato con il resto del sorgente oggetto del riuso, consentono di misurare la qualità di un applicativo: se i test non ci sono o sono quantitativamente scarsi, rispetto al volume del codice sorgente, l’applicativo ha un problema. Se posso contare il numero dei test e verificare che sia maggiore di zero, allora, posso misurare un aspetto della qualità del codice. Tra l’altro uno dei metodi per sviluppare software è il TDD, il test driven development, ossia, la scrittura del codice sorgente a partire dai test, proprio perché i test sono importanti sotto ogni profilo nello sviluppo di un applicativo software.
Se spendo 25 milioni di euro per un applicativo (butto una cifra a caso, ma non troppo) mi aspetto di trovare un congruo numero di test: non sono un esperto di metriche per valutare la congruità dei test rispetto al codice sorgente, ma, oggettivamente, è ben difficile accettare che il valore dei test sia mille euro su 25 milioni; ragionevolmente, dovrebbe essere di almeno un milione. Applicare una licenza open source ad un programma, non è una panacea per tutti i mali, ma, un passo verso trasparenza e sicurezza per la PA, un passo molto importante e significativo.
_
Note
Un grande ringraziamento all’avvocato Carlo Piana per i contributi e spunti sull’articolo.
- sono aziende che affittano dei server su cui viene spesso preinstallato linux, quindi non viene necessariamente venduto o affittato il software, ma, rientra in un’offerta più ampia ↑
