Più si diffondono i progetti open source, più sono le probabilità che vengano utilizzati senza le dovute precauzioni. In questo contesto si rivela fondamentale poter contare su una sua governance che definisca dettagliatamente policy e processi relativi all’uso di strumenti open source. È esattamente ciò che serve a un’organizzazione per conoscere gli strumenti su cui basa la propria strategia e i rischi ad essi legati
Questa governance dedicata supporta gli sviluppatori nell’uso di strumenti open source per ottimizzare il software e la sua gestione. Esistono infatti alcuni accorgimenti che si possono adottare per minimizzare i rischi di sicurezza e aumentare la responsabilità. Eccone alcuni.
Scansionare le librerie open source per identificare vulnerabilità
Le librerie open source nei progetti di sviluppo software sono incredibilmente apprezzate e sfruttate. Il successo di molti software si basa proprio sulla possibilità di trarre vantaggio dai progetti così creati. Utilizzare Internet sarebbe ad esempio impossibile se non si potesse fare affidamento su un abbondante numero di progetti open source.
Usando librerie open source, i developers possono focalizzarsi sulle caratteristiche specifiche di un’applicazione. Si ottengono così software ben testati e maturi, in grado di gestire protocolli standardizzati, come il secure sockets layer e HTTP.
Può però capitare che le librerie open source presentino bug e vulnerabilità di sicurezza, che possono avere un effetto catastrofico. Per esempio, la vulnerabilità Log4Shell nella libreria di log open source Log4j di Apache ha messo a rischio milioni di sistemi. Dopo questo caso, le organizzazioni sono tempestivamente corse ai ripari per patchare il proprio software ed evitare il controllo non autorizzato di sistemi sicuri.
Per evitare danni legati alle vulnerabilità delle librerie open source è necessaria la scansione delle dipendenze di un progetto in modo da individuare quelle più a rischio. Con OWASP Dependency-Check si ottiene ad esempio un report con le dipendenze vulnerabili, insieme al Common Vulnerabilities and Exposures (CVE). Ci sono diversi modi per eseguire OWASP Dependency-Check, attraverso un’interfaccia a riga di comando, un plugin Apache Maven, un task Ant o un plugin Jenkins, che consente una facile integrazione in qualsiasi pipeline CI/CD.
L’uso di uno tool come questo, che crea report attivabili, è utile però solamente quando il processo viene applicato intorno allo strumento. Meglio quindi eseguire OWASP Dependency-Check su un programma coerente per scansionare la codebase contro gli ultimi aggiornamenti dei CVE scoperti di recente e dedicarsi poi alla gestione e alla pianificazione per i CVE identificati.
Adeguarsi alle licenze dirette e indirette
Quando si usano dipendenze open source, è utile considerare le licenze che ne regolano l’uso per sapere come usare, copiare e distribuire il software. Al variare delle tipologie di applicazione e dei modelli di distribuzione, il codice sorgente potrebbe non permettere l’uso di alcuni strumenti open source. Per esempio, nella terza versione della “GNU General Public License” viene precisato che ogni progetto basato sul lavoro di un altro creatore con licenza GPLv3 deve essere pubblicamente disponibile proprio come il progetto originale.
Infrangere i termini di queste licenze comporta per l’organizzazione costose conseguenze legali. ScanCode Toolkit è uno strumento a riga di comando indipendente che analizza un progetto e crea un report delle varie licenze che governano i componenti open source nel suo codice sorgente. È anch’esso completamente open source e disponibile su GitHub, semplifica la comprensione delle dipendenze open source di un progetto e ne abbrevia i tempi di gestione.
Per le dipendenze dirette il codice sorgente dell’applicazione fa esplicito riferimento a certi progetti software di terze parti. Ci possono però essere anche dipendenze indirette, progetti software di terze parti che le dipendenze dirette utilizzano.
Gli sviluppatori devono obbedire alle licenze delle dipendenze dirette, poiché il loro codice sorgente è costruito su questi progetti software di terze parti. Deve però fare lo stesso anche per le dipendenze indirette, anch’esse parte del codice sorgente di un software. ScanCode Toolkit è scritto in Python e progettato per essere estensibile, con un sistema di plugin per aggiungere funzionalità alle scansioni.
Identificare i “code owner” su GitHub
Per rendere gli sviluppatori responsabili delle nuove modifiche che introducono nei progetti open source va utilizzata la funzione “code owners” su GitHub. In questo modo, all’interno di un repository GitHub, gli utenti specifici possono essere designati come i revisori dei cambiamenti introdotti in tratti del loro codice. Ciò significa che riceveranno una notifica quando una richiesta di pull si apre alle parti corrispondenti del repository loro assegnato.
Accoppiata con la branch protection, questa funzione permette ai developer di rivedere tutte le richieste di pull prima che si uniscano al branch principale. Ne consegue un aumento del livello di garanzia di qualità, perché i collaboratori che hanno più familiarità con i file modificati possono verificarne i cambiamenti.
