Dipendenze open source, best practices per gli sviluppatori

Il software open source (OS) è ovunque. Indipendentemente dal settore, ogni azienda fa affidamento sul software per soddisfare le proprie esigenze di business; e la maggior parte delle applicazioni in uso contiene elementi di codice OS. La migrazione verso sempre più complesse applicazioni cloud-native fa registrare un aumento del rischio legato alla sicurezza del software, che costringe le organizzazioni a implementare pratiche di gestione delle componenti open source durante l’intero ciclo di vita dello sviluppo del software (SLDC – Software Development Life Cycle) e ad adottare gli strumenti corretti per gestire i rischi correlati.

La formazione degli sviluppatori alla sicurezza open source e l’implementazione di validi strumenti di analisi della composizione del software (SCA) sono entrambi passaggi cruciali per proteggere il codice rispetto ai rischi veicolati dal software open source.

“Software risk is real”

Il rapporto OSSRA 2022 offre alcuni spunti essenziali sull’ampia adozione del software open source e sui relativi rischi per la sicurezza. In esso vengono infatti esaminati 17 settori industriali, quattro dei quali – hardware per computer e semiconduttori, sicurezza informatica, energia e tecnologia pulita, Internet of Things – contenevano componenti open source nel 100% del codice analizzato; nei restanti settori, la percentuale di elementi open source all’interno del codice risultava compresa tra il 93% e il 99%.

Il rapporto rileva che, sebbene i conflitti di licenza appaiano diminuiti (sono state riscontrate problematiche nel 53% del codice, mentre nel 2020 si raggiungeva il 65%) aumentano i casi di dipendenze non esaminate: ovvero, quando gli sviluppatori introducono dipendenze open source spesso non sono a conoscenza delle sotto-dipendenze contenenti ulteriori termini e condizioni di licenza. Ad esempio, alcune versioni del popolare componente node.js includono una dipendenza che sfrutta il codice concesso ai sensi della licenza CC-SA 3, la quale potrebbe imporre requisiti indesiderati e richiedere una valutazione legale rispetto ai potenziali problemi di IP.

Sebbene la diminuzione dei conflitti di licenza e delle vulnerabilità ad alto rischio appaia incoraggiante, resta il fatto che più della metà dei codici sorgente controllati conteneva conflitti di licenza e includeva, in percentuali simili, vulnerabilità ad alto rischio. C’è un dato ancora più preoccupante: tra i 2.097 codici sorgente controllati per cui erano state anche eseguite valutazioni del rischio, l’88% conteneva versioni obsolete di componenti open source. In altre parole i necessari aggiornamenti o patch, pur disponibili, non erano stati applicati.

Senza esplorare le diverse ragioni che spingono a non mantenere aggiornato il software, una possibile soluzione che eviti problemi futuri all’organizzazione è realizzare un inventario accurato e aggiornato dell’open source utilizzato all’interno del codice, visto che un componente non aggiornato può essere ignorato fino a quando non risulti vulnerabile a un exploit ad alto rischio.

Questo è esattamente ciò che è successo con Log4j. Sebbene l’exploit fosse effettivamente pericoloso, il panico e la perdita di clienti che ne sono derivati sono stati in gran parte causati dalle organizzazioni che non sapevano dove si trovasse Log4j all’interno dei loro sistemi e applicazioni: diverse di esse, infatti, hanno faticato innanzitutto per controllare se fosse presente o meno.

Gestire le dipendenze open source: best practice preventive

Stabilire un programma completo di gestione del software open source può sembrare un’impresa talmente ardua da apparire scoraggiante, ma esistono alcune best practice che possono aiutarti a iniziare.

Prevedere una corretta governance del software aiuta a proteggere le risorse e i dati della tua organizzazione, evitando i problemi che sorgono quando viene annunciata una vulnerabilità zero-day: ciò implica la definizione di una strategia, l’impostazione di un processo di approvazione e l’esecuzione di un audit completo circa le dipendenze legate al software open source.

1. Definisci una strategia

La creazione di una policy open source per la tua organizzazione riduce al minimo i rischi legali, tecnici ed economici derivanti dall’utilizzo di software open source. Policy e programmi di governance possono concentrarsi sia sull’impiego del codice open source nel processo di sviluppo sia sull’utilizzo del software stesso, così facilitando, ad esempio, le operazioni e il supporto del reparto IT. Alcune organizzazioni creano persino un ufficio dedicato a gestire qualsiasi attività coinvolga il software open source.

Il primo passo per creare una policy per l’open source è identificare i tuoi stakeholder principali: può trattarsi degli sviluppatori il cui lavoro sarebbe direttamente influenzato dalle policy adottate, come anche dei dirigenti di alto livello che dovranno approvare le policy e assumersi i rischi dell’utilizzo del software open source. Le parti interessate includono anche personale IT, manager dei team che utilizzano software open source, esperti legali che forniscono consulenza sulla conformità delle licenze open source e software architects, tutti ruoli chiave che dovrebbero essere coinvolti il prima possibile in tale processo.

La strategia dovrebbe delineare gli obiettivi della tua organizzazione per l’incorporazione di software open source, identificare la quantità di software open source attualmente in uso e definire i target relativi al suo impiego. La policy dovrebbe anche definire quali licenze open source sono incluse e se eventualmente differiscano tra il software sviluppato internamente e il software acquistato da terzi.

È consigliabile stabilire un processo di approvvigionamento e selezione del software open source che sia, idealmente, in grado di indicare esplicitamente i siti Web, i repository e i metodi approvati per ottenere software open source e aiutare a decidere se un determinato pacchetto sia adatto al lavoro da svolgere. Dovrebbe inoltre determinare chi possa scaricare software open source e da dove, nonché se sia richiesta un’autorizzazione prima di scaricarlo, utilizzarlo o distribuirlo.

2. Stabilisci un processo di approvazione

È inoltre necessario stabilire un processo che determini se un pacchetto software soddisfi le esigenze e gli standard di qualità dell’organizzazione. Alcuni criteri da considerare includono la qualità del codice, il livello di supporto, la maturità del progetto, la reputazione dei contributor e i trend di vulnerabilità coinvolti.

Un processo che tenga conto di questi criteri proteggerà i team dal rischio di ritrovarsi con versioni diverse dello stesso pacchetto software sparse all’interno del codice dell’organizzazione, ognuna delle quali potrebbe essere stata – o meno – corretta e aggiornata.

Affinché un processo di approvazione funzioni, è necessario che le richieste abbiano riscontro in tempi rapidi: a tal fine può essere utile la creazione di un elenco open source pre-approvato.

3. Crea un processo di audit per identificare il software open source

Oltre a garantire la conformità con le politiche interne, l’audit fornisce un quadro completo del software open source in uso. Ciò ti aiuterà a definire e individuare i componenti; un fattore determinante per il mantenimento della conformità delle licenze open source e, soprattutto, qualora sia divulgata una vulnerabilità.

Dovresti eseguire regolari scansioni open source durante il ciclo di vita dello sviluppo software (SDLC), ma anche assicurarti che venga eseguita una scansione finale ogni volta che sia realizzata un’applicazione che incorpora al suo interno software open source, specialmente laddove ci si affidi a componenti di terze parti.

Per individuare i componenti vulnerabili all’interno delle tue applicazioni, devi prima definire TUTTI i componenti open source inclusi. Per farlo è necessario considerare ogni versione e fork del codice, analizzare i componenti in formato sorgente e binario, analizzare il software in cui è spesso incorporato l’open source e guardare oltre ciò che è stato dichiarato nel sistema di gestione dei pacchetti. L’automazione di questa attività evita ai team di dover realizzare degli inventari manuali (spesso imprecisi) dell’open source, consentendo inoltre di individuare rapidamente i componenti vulnerabili e di sapere immediatamente quando vengano segnalate nuove vulnerabilità. La predisposizione di un inventario completo è il primo passo da compiere perché, se non sai esattamente cosa è presente nel tuo perimetro, non puoi assicurarti di mantenerlo aggiornato.

In seguito all’audit sarai in grado di creare un elenco di attività e un relativo piano finalizzato a colmare eventuali lacune e raggiungere la piena conformità. Tali attività possono includere la fornitura o la disponibilità del codice sorgente – inclusi gli avvisi richiesti nel codice o nella documentazione – e l’aggiornamento del contratto di licenza con l’utente finale. Nei casi in cui la conformità non sia raggiungibile sarà necessario cercare delle alternative, ad esempio ricorrendo a librerie diverse.

Il contributo di Synopsys

L’analisi della composizione del software (SCA) Black Duck® può contribuire a una gestione ottimale del proprio programma di policy open source. Black Duck SCA offre impostazioni dei modelli personalizzabili, in modo da poter creare criteri particolareggiati e stabilire le priorità per semplificare le attività di sicurezza.

Basandosi su modelli proprietari, i Black Duck Security Advisories (BDSA) realizzano una ricerca di sicurezza avanzata che va oltre ciò che forniscono le fonti pubbliche: ciascun BDSA contiene indicazioni utili per la remediation, informazioni tecniche approfondite, punteggio CVSS (incluse le metriche temporali) e, ove disponibile, analisi dell’impatto della vulnerabilità per aiutare a determinare se il codice vulnerabile sia utilizzato dall’applicazione. L’abbinamento di un BDSA con la gestione avanzata delle policy consente, sulla base di più attributi-chiave, di assegnare a ciascuna vulnerabilità il grado di priorità corretto in ottica di remediation.