L’Europa dipende in larga parte da software open-source progettati principalmente all’estero. All’interno del Mercato unico digitale Europeo la maggior parte del software è assemblata online e più della metà proviene da (repositories di) software open-source realizzati oltre confine.
Alcune università, piccole, medie e grandi imprese, un gruppo di interesse specializzato e un consiglio consultivo con competenze chiave nell’ambito del software open-source, si sono riuniti in una partnership strategica per la creazione di nuovi metodi e approcci per accelerare lo sviluppo di software più efficienti e sicuri.
In questo articolo vedremo brevemente il tentativo del progetto AssureMOSS (Assurance and certification in secure Multi-party Open Software and Services - https://assuremoss.eu) di affrontare la sfida dei software open-source “progettati ovunque, ma garantiti in Europa”. Il progetto, di durata triennale (Ottobre 2020 - Settembre 2023), è finanziato dalla Commissione Europea nell'ambito del programma HORIZON 2020 [1].
La corsa ai software assemblati e il paradigma MOSS
Nell'ultimo decennio, tra le molteplici innovazioni, due principali caratteristiche in particolare hanno modificato e condizionato radicalmente i progetti di sviluppo software [2]. Innanzitutto, l'accorciamento del ciclo di feedback tra i team di sviluppo e la risposta ai prodotti che questi team rilasciano (ad esempio, A/B testing, DevOps) ha portato a uno sviluppo frenetico con modifiche dei prodotti più rapide. In secondo luogo, gli sviluppatori si sono sempre più concentrati sulla differenziazione delle funzionalità nei loro prodotti finali, affidandosi però, in misura crescente, a terze parti per tutto il resto (implementazione cloud, uso estensivo di framework aperti come OpenSSL [3] or Node.js [4], oppure uso di prodotti più ristretti ma con protocolli, procedure, librerie ed API [5] comunque open-source). Tutto ciò ha portato a uno sviluppo che vede coinvolte diverse parti (detto multi-stakeholder, dall’Inglese: multi-parte interessata): la risultante è un assemblaggio operato da diversi attori, ognuno con le proprie pratiche/politiche di sicurezza e privacy.
Possiamo qui già introdurre un acronimo che utilizzeremo nel resto dell’articolo. Il software moderno è basato su un paradigma chiamato Multi-party Open Software and Services (MOSS). Pertanto, una software company che sviluppa un prodotto rappresenta solo uno dei protagonisti coinvolti nel processo di garanzia della sicurezza software su quello stesso prodotto.
Queste parti coinvolte includono le comunità di sviluppo dei Sistemi Operativi, ad esempio, nella creazione di aggiornamenti di sicurezza, o le società che forniscono nuovi servizi di sicurezza o aggiornamenti alle interfacce esistenti. Il paradigma MOSS si applica certamente al caso delle imprese più grandi, mentre le aziende più piccole, come le PMI e le start-up, potrebbero avere una supply chain più corta che si basa principalmente su software gratuito e open source (FOSS - Free and Open Source Software).
Quest’ultimo è la spina dorsale dell'industria del software: quasi l'80% dei prodotti commerciali oggi contiene almeno un componente FOSS al punto che il Parlamento Europeo ne ha riconosciuto formalmente il ruolo chiave. È interessante notare anche la tendenza progressiva a ridurre la porzione di codice prodotto internamente dalle società di sviluppo software. Alla fine degli anni '90, oltre il 95% dello stack software era costituito da codice sviluppato in proprio. Solo i Database e i Sistemi Operativi provenivano da fornitori in modalità closed-source con licenza. Osservando il trend attuale si può notare come al 2019 invece, la porzione di codice prodotto internamente sia diminuita drasticamente fino a rappresentare solo il 5% della torta: browser, framework UI, gestori di pacchetti, server applicativi, piattaforme di microservizi, container, sistemi operativi containerizzati, sono tutti generalmente componenti software di terze parti (per lo più open-source) che le software companies utilizzano quotidianamente [6-7-8].
Certificazione e ricertificazione del software
Questa evoluzione del processo di sviluppo software in cicli rapidi e frammentati implicherebbe altrettanti processi/cicli di certificazione e garanzia della sicurezza software a causa delle numerose modifiche che hanno conseguenze sulla sicurezza e sulla privacy (una nuova vulnerabilità potrebbe per esempio essere introdotta dall’utilizzo di una nuova libreria in grado di accedere a dati personali ed eventualmente trasmetterli). Pertanto il nuovo paradigma per la garanzia della sicurezza dovrebbe essere "leggero e continuo" rispetto al precedente paradigma “rigido e fisso”. Non si dovrebbe dunque parlare di certificazione ma piuttosto di certificazione, ricertificazione e valutazione del rischio.
Il fatto che lo sviluppo del software sia, in effetti, un'attività multi-stakeholder (dove alcuni stakeholder sono nascosti in sub-sub-sub dipendenze su librerie di terze parti) significa che le tecniche di garanzia dovrebbero funzionare in un ecosistema frammentato con più fonti di artefatti (ad es. dalla comunità open-source), diverse tecnologie e linguaggi e diversi domini decisionali. Di conseguenza, un nuovo paradigma per la garanzia della sicurezza implica un approccio "intelligente e flessibile", ovvero in grado di apprendere, adattarsi e migliorare nel tempo con la disponibilità di nuovi dati e feedback aggiuntivi.
A meno che non vengano create tecniche di garanzia della sicurezza innovative, leggere e intelligenti, in grado di integrarsi con più parti interessate e con sviluppatori dal ritmo serrato, la sicurezza continuerà a essere penalizzata [9] dalla corsa alla produttività dei team di sviluppo, sollecitati a distribuire nuove funzionalità su base giornaliera.
Lo sviluppo veloce e multi-stakeholder pone anche una sfida alla certificazione del software sicuro. Gli schemi di certificazione di sicurezza esistenti, inclusi quelli per progetti open-source, ad esempio Core Infrastructure Initiative (CII) Badge Program [10], si concentrano sulla certificazione che i progetti software seguano determinate best practice di sicurezza. In sostanza, questi schemi si concentrano sul processo di sviluppo del software. Tuttavia, nei progetti software moderni, il processo di sviluppo sta diventando più fluido e continuamente adattato dagli sviluppatori (invece di essere rigido e applicato a livello centrale). Di conseguenza, le strutture coinvolte in ogni fase potrebbero non disporre delle risorse necessarie per acquisire e mantenere tali certificazioni.
La sfida del progetto AssureMOSS
Da quanto detto si sarà certamente percepita la necessità di un cambio di prospettiva da parte dell’Unione Europea, che ha provato a innescare un nuovo approccio finanziando il progetto AssureMOSS . Il progetto coinvolge un team composto da 4 Università (Delft, Gotheborg, Trento, Vienna), 3 PMI innovative (Pluribus One, FrontEndArt, Search-Lab), 2 grandi imprese (SAP, Thales), l’organizzazione EU-VRi e un Advisory Board composto da figure strategiche del mondo dell’industria e dell’Open Source Software (OSS).
Nello specifico, AssureMOSS propone di attuare il passaggio dalla valutazione della sicurezza basata sui processi a quella basata sugli artefatti (Models, Source code, Container images, Services), supportando tutte le fasi del ciclo di vita continuo del software (progettazione, sviluppo, implementazione, valutazione e backup).
AssureMOSS adotta quindi un approccio completo alla garanzia della sicurezza e alla ricertificazione e ha l'ambizione di contribuire a ogni fase del processo di sviluppo del software, grazie ad un insieme coerente di tecniche automatizzate e leggere che consentano alle società di software di valutare, gestire e ricertificare i rischi per la sicurezza e la privacy associati allo sviluppo rapido e alla distribuzione continua di software aperto multiparte e servizi . In definitiva, il progetto mira a supportare la creazione di software MOSS più sicuro.
L'idea chiave è quella di supportare meccanismi per screening leggeri e scalabili, applicabili automaticamente all'intera popolazione di componenti software mediante:
• uso di Machine Learning per l’identificazione intelligente di problemi di sicurezza tra gli artefatti;
• analisi e verifica delle modifiche attraverso tracciamento continuo di effetti collaterali sulla privacy e sulla sicurezza;
• costante analisi dei rischi e valutazione della sicurezza del software (con un occhio particolare agli impatti potenziali sul business causati da prodotti potenzialmente vulnerabili).
Il progetto genererà non solo una serie di metodi innovativi e strumenti open source, ma anche set di dati di benchmark con migliaia di vulnerabilità e codice che potranno essere utilizzati da altri ricercatori.
Gli strumenti AssureMOSS aiuteranno per esempio a risparmiare tempo nella ricerca di bug e vulnerabilità attraverso il vaglio semiautomatico di aggiunte, rimozioni e modifiche nei repository di codice (analisi dei commit [11]), accelerando anche in questo modo quindi il processo di valutazione e analisi del software.
Il cambio di prospettiva (artefatti vs processi) e il concetto di ricertificazione continua del software sviluppato, sono dunque alla base di una sfida estremamente ambiziosa: stabilire le linee guida che potranno essere utilizzate, ad esempio, dagli organismi di certificazione e standardizzazione per fondare uno schema di certificazione incentrato sugli artefatti per il software MOSS.
L'intuizione di base è ben riassunta da una pratica ben nota in ambito medico sanitario [12] e che qui adattiamo allo scopo: “Lo screening è definito come l'identificazione preventiva di una malattia in una popolazione apparentemente sana e asintomatica mediante test (di componenti software), esami o altre procedure che possano essere applicate rapidamente e facilmente alla popolazione target. […] Nel sostenere i programmi di screening, è importante evitare di imporre modelli derivati da ambienti ad alta efficienza con sistemi sanitari avanzati e schemi di verifica (della sicurezza) sofisticati e costosi, a società, processi, (sviluppatori e utenti) di paesi che non dispongono dell'infrastruttura e delle risorse necessarie per ottenere un'adeguata prevenzione sulla popolazione”.
1 Il progetto AssureMOSS è regolato dal Grant Agreement n° 952647, ed è finanziato per un totale di 4.689.425 Euro, www.pluribus-one.it/it/ricerca/progetti/assuremoss
2 Jan Bosch, Speed, Data, and Ecosystems: Excelling in a Software-Driven World, CRC Press, 2016
3 OpenSSL è un'implementazione open source dei protocolli SSL e TLS, disponibile per la maggior parte dei sistemi operativi unix-like, inclusi GNU/Linux e macOS, e anche per Microsoft Windows, www.openssl.org
4 Node.js è un runtime system open source multipiattaforma orientato agli eventi per l'esecuzione di codice JavaScript, costruita sul motore JavaScript V8 di Google Chrome. Molti dei suoi moduli base sono scritti in JavaScript, e gli sviluppatori possono scrivere nuovi moduli in JavaScript, https://nodejs.org/it/
5 API, acronimo di Application Programming Interface, www.redhat.com/it/topics/api/what-are-application-programming-interfaces
6 Black Duck's Future of Open Source Survey, 2015
7 Holger Mack,Tom Schröer, Security Midlife Crisis, SAP Product Security Summit 2019
8 http://www.europarl.europa.eu/oeil/popups/ficheprocedure.do?lang=en&refe...
9 According to CVE Details, 2017 smashed the record of vulnerabilities of the previous years (14714 in 2017 vs the previous record of 7946 in 2014). Unfortunately, 2018 has done even worse (16555 vulnerabilities). https://www.cvedetails.com/browse-by-date.php
10 https://www.coreinfrastructure.org
11 https://wiki.ubuntu-it.org/Programmazione/Git/Commit
12 https://www.who.int/cancer/prevention/diagnosis-screening/screening/en/
13 Eoin Woods, Democratizing Software Architecture, Keynote at ICSA 2019, online at https://speakerdeck.com/eoinwoods/democratising-software-architecture
14 www.pluribus-one.it/it/chi-siamo/blog/88-cybersecomics/111-bug
