A prescindere dai meriti del modello di sviluppo trasparente e condiviso dell’open source, questa modalità presenta caveat specifici di cui occorre tenere conto nell’ambito della cyber security. Da decenni, il codice open è diventato una fonte primaria di componenti per lo sviluppo applicativo, non solo per creare i programmi con licenza gratuita, ma per comporre gli stack software di quasi tutti i servizi e i prodotti commerciali.
Nessuno oggi sviluppa software partendo da zero, ed è naturale che le componenti mature in open source equipaggino servizi di sistema, database, interfacce Web e molto altro. Secondo le stime, più della metà del software commerciale è fatto da parti open source. Codice che spesso non viene citato e non può essere garantito nel ciclo di vita dell’applicazione.
Va da sé che questo comporti dei rischi a cui prestare attenzione sul fronte della security. Vediamo quali.
Indice degli argomenti
Le vulnerabilità delle librerie open source si traferiscono alle applicazioni
Sono molti i casi di vulnerabilità di componenti e librerie open source che hanno aperto le porte ad attacchi cyber alle aziende. L’ultimo, esploso nel dicembre scorso, ha riguardato una vulnerabilità di Log4j (una utility di logging di Apache) che permetteva agli attaccanti d’iniettare codice per sottrarre dati, installare malware o altro.
Negli anni passati, il bug Hearthbleed, scoperto nella libreria di supporto a OpenSSL (per la creazione di canali di comunicazione sicuri via Web) permetteva agli attaccanti di violare le informazioni cifrate. “Chi sviluppa software ottiene grandi vantaggi dalle librerie open source, perché risparmia tempo e può concentrarsi sulle componenti creative e di valore dell’applicazione – spiega Stefano Taino, CEO di Cryptonet Labs – da qui, l’uso diffuso dei componenti open, spesso effettuato in violazione delle licenze che imporrebbero citazioni e limitazioni d’uso”.
Il risultato è che parte del codice incorporato nelle applicazioni e servizi aziendali non è conosciuto né censito, quindi escluso dagli aggiornamenti e patch che periodicamente vengono fatti per eliminare i bug funzionali e altre vulnerabilità.
Il rischio delle librerie obsolete e le difficoltà d’aggiornamento
Per una buona sicurezza delle applicazioni servirebbe verificare periodicamente l’esistenza di vulnerabilità nelle librerie ed effettuare aggiornamenti con le ultime versioni. “Cosa difficile da fare quando le librerie sono annegate in software di terze parti di cui non si conosce la composizione” spiega Taino “In altri casi, non arrivano gli aggiornamenti, oppure ci sono dipendenze software tali da compromettere il funzionamento dell’applicazione”.
Il risultato di queste difficoltà è fotografato nell’ultimo report State of Software Security: Open Source Edition di Veracode con i dati di sintesi sulle scansioni di vulnerabilità a decine di migliaia di software realizzate con la piattaforma d’analisi del vendor. “Oltre il 79% delle librerie open source utilizzate risulta non aggiornato alla versione più recente” spiega, invece, Paolo Restagno, vice president per l’Europa di Veracode. “Senza aggiornamenti, anche le vulnerabilità già note e risolte, come Log4J, continuano a essere una minaccia per la sicurezza delle aziende”.
Dallo stesso Report, JavaScript risulta essere il linguaggio di sviluppo applicativo con maggiori rischi, anche per il fatto che il 90% del codice applicativo JavaScript è costituito da librerie open source. Segue .NET con un peggioramento a partire dalla versione 5.0, da quando Microsoft ha aperto agli sviluppatori la possibilità di usare le componenti di terze parti. Al di là delle difficoltà nel reperire aggiornamenti puntuali alle librerie open source e d’implementarli a scopo preventivo, per prendere contromisure è importante riuscire a stimare il livello di rischio associato a nuove vulnerabilità o minacce circolanti in rete.
L’audit sulle librerie per garantire la sicurezza anche sotto il profilo legale
Servizi specifici e tecnologie analitiche sono oggi di grande aiuto per ricercare in modo automatico le componenti in open source impiegate all’interno delle applicazioni oltre che per individuarne le vulnerabilità. “Fare l’audit delle librerie nel proprio portafoglio applicativo aiuta a sapere cosa si sta usando e se lo si fa in modo legale”, spiega Paolo Restagno.
Le componenti open source hanno licenze proprie che, in qualche caso, permettono l’uso libero mentre in altri è condizionato, per esempio, dall’obbligo di condividere gli sviluppi con la comunità. “L’audit serve a sciogliere i rischi di sicurezza anche sul fronte legale – continua Restagno – sapere cosa c’è dentro un’applicazione consente, per esempio, di verificare il rispetto dei contratti con le terze parti che fanno sviluppo”.
L’auditing viene effettuato mediante confronto con le basi dati contenenti il catalogo delle risorse open source e delle versioni in circolazione, quindi con il database delle vulnerabilità di security già identificate. Ma non basta. “Sulla nostra piattaforma sfruttiamo le informazioni contenute nel National Vulnerability Database (NVL) – spiega Restagno – ma siccome tra segnalazioni, verifiche e inserimenti nel registro NVL possono passare dai 6 agli 18 mesi, abbiamo un laboratorio che impiega strumenti d’intelligenza artificiale per identificare, dalle iniziali segnalazioni tra sviluppatori e dai contenuti nei repository di GitHub, i problemi prima che divengano di pubblico dominio (e target per exploit, ndr). Questo ci consente di coprire i gap temporali che avremmo con NVL”.
Una piattaforma per l’analisi del codice
L’auditing del codice open source è supportato nella piattaforma d’analisi delle vulnerabilità Veracode con uno specifico add-on. “Al caricamento del nuovo codice da parte del cliente, il sistema individua le componenti open presenti, verifica le licenze associate e quindi produce un report a vantaggio di chi deve decidere se e quando intervenire”, spiega Restagno.
Analisi sistematiche, integrate nei processi di sviluppo e di deploy applicativi realizzati con la metodologia DevSecOps permettono di ridurre al minimo i rischi connessi con le vulnerabilità open source: “A ogni modifica e ricompilazione, il codice viene mandato automaticamente, via API, sul servizio d’analisi, ottenendo le segnalazioni che servono a rimediare, per esempio, aggiornando una libreria difettosa”.
Usata in modo estemporaneo su applicazioni legacy, la piattaforma Veracode può trovare debiti di sicurezza in centinaia di librerie: “Situazioni che possono essere rimediate con una montagna di lavoro e molto tempo” spiega Restagno. “Da parte nostra offriamo funzioni d’aiuto che approfondiscono l’analisi per capire se l’applicazione fa uso dei metodi vulnerabili della libreria (non tutti potrebbero essere pericolosi, ndr). Questo permette di determinare se c’è o meno un rischio immediato e stabilire le priorità d’intervento”.
Il tema della sicurezza applicativa che deriva dall’uso di componenti open source è stato per lungo tempo ignorato: “Il risultato è che ci vorranno anni per recuperare i gap di sicurezza accumulati. Senza i supporti per valutare e mitigare il rischio si diventa facilmente un bersaglio per il cybercrime”, conclude Restagno.
Contributo editoriale sviluppato in collaborazione con Veracode Cryptonet
