Anche il mondo open source richiede bug bounty? Questo quesito, che un tempo avrebbe scatenato l’ilarità di ogni informatico, oggi richiede una riflessione obiettiva. Perché oggi sappiamo che vulnerabilità come Log4Shell, e prima di lei molte altre ancora, ci hanno dimostrato come anche il codice open source può contenere errori di programmazione capaci di conseguenze drammatiche.
Proprio per questo, anche il codice open source richiede un programma di bug bounty serio e professionale. E spesso quello offerto dalla comunità non è sufficiente.
Indice degli argomenti
Bug bounty: un cambio di modello
Partiamo col ricordare che per bug bounty si intende un programma per la ricerca di vulnerabilità in un sistema informatico, al fine di mitigarle e, dunque, garantire la sicurezza del sistema stesso. Il bug bounty si è evoluto nel corso degli anni, sia in termini di strumenti che di strategie.
Per esempio, è passato dall’essere un programma dedicato a lupi solitari a una proposta dedicata a team o comunità. È passato, inoltre, da attività sporadica a disciplina ben codificata in termini di procedure e professionalità.
E poi è cambiato il target: tipologia di codice da analizzare, linguaggi di programmazione con nuove problematiche, filosofie di sviluppo software che portano in dote specifiche vulnerabilità.
Ed è proprio qui, su questo terreno, che il bug bounty incrocia il mondo dell’open source.
Il bug bounty in aiuto dell’open source
“Negli ultimi anni”, spiega Luca Manara, CEO e Co-fondatore di UNGUESS, “sono sorti molti dubbi sulla sicurezza del mondo open source. L’open source funziona, ovviamente, ma ci si è resi conto che, mentre tutti ne fruiscono, su diversi progetti sono poche le persone che si impegnano a sostenere e verificare il codice”.
Il riferimento di Manara è chiaro: sebbene l’open source sia una manna per il mondo del software, spesso è percepito in modo errato, cioè come un serbatoio di tecnologia gratuita da cui attingere senza, tuttavia, contribuire. E questo, va da sé, porta a vulnerabilità gravi.
Ecco perché il bug bounty deve essere applicato, senza sconti, anche al codice open source.
La fragilità dell’open source
A sottolineare questa necessità c’è anche il rapporto State of Software Security 2023 di Veracode, che titola una delle sue sezioni Fragility of Open Source. Una decina di pagine fitte di dati e considerazioni che non fanno che confermare le parole di Manara.
Emerge, per esempio, che metà dei repository di progetti open source non ha avuto aggiornamenti per più di un anno, mentre uno su dieci non ne ha avuti negli ultimi sei anni.
Un dato che da solo non basta a definire il livello di sicurezza di un software, certo, ma che legato alla diffusione di soluzioni open source, soprattutto a livello di librerie, spiega che la presenza di vulnerabilità nel codice aperto è tutt’altro che remota.
Il report di Veracode offre un dato che spiega bene il fenomeno: il 92% delle applicazioni Javascript utilizza almeno una libreria gestita da un solo sviluppatore e che non ha ricevuto aggiornamenti nell’ultimo anno. L’humus perfetto per il proliferare di bug.
Bug bounty, sicurezza e librerie
La soluzione? L’adozione di modelli di sviluppo più orientati alla sicurezza, che tuttavia non può essere certo imposta al settore open source. Giocoforza, quindi, il pallino passa proprio al bug bounty, cioè la creazione di programmi che invoglino i ricercatori e analisti a scovare le più gravi vulnerabilità. E, se si focalizza sull’open source, occorre considerare nuove criticità.
La principale è quella delle librerie: il mondo open source offre una quantità disarmante di librerie, più o meno conosciute, che sono prese di peso e incluse nel codice di nuovi software. Una grande comodità per gli sviluppatori, ma che cela una insidia.
Una libreria, per natura, viene integrata nel proprio codice senza verificarne la qualità o sicurezza. Una libreria consente di risparmiare tempo e costi nel ciclo di sviluppo e, raggiunto questo obiettivo, è raro che si proceda alla sua verifica in termini di sicurezza. Se, dunque, la libreria ha una qualche vulnerabilità, questa viene ereditata anche dal nuovo software.
Librerie come veicolo di vulnerabilità
Luca Manara conferma: “Spesso nel processo di sviluppo si vanno a includere librerie, e al tempo stesso vulnerabilità, senza nemmeno rendersene conto: si prende quel che c’è, quel che offre la libreria, senza tenere conto di nient’altro”.
Un comportamento che forse può essere considerato comprensibile, oggi, solo per chi sviluppa per hobby, ma che diventa molto pericoloso quando la programmazione tocca ambiti professionali. Senza considerare il tema della nidificazione di librerie: ovvero quando si scrivono librerie software richiamando risorse di altre librerie.
E il risultato è che la verifica del codice diventa difficile perfino per lo stesso programmatore.
Piattaforme per il bug bounty
Da qui, la necessità di dedicare bug bounty anche al software open source, anche se il problema, a questo punto, è organizzare un’attività così complessa e specializzata. È qui che entrano in gioco apposite piattaforme con le quali le aziende possono creare e avviare bug bounty sui propri software.
In questo modo, si possono sfruttare i servizi di verifica e analisi del codice di appositi professionisti. “Per esempio con UNGUESS Security, la nostra piattaforma”, spiega Manara, “ogni azienda entra in contatto con una comunità di oltre 500 hacker etici, accuratamente selezionati, per organizzare bug bounty e scovare vulnerabilità più o meno gravi nei propri software, che contengano o meno anche componenti open source”.
Sfruttando piattaforme di questo tipo, l’azienda affida il controllo del software ad appositi professionisti e può così concentrarsi sul proprio business, mentre centinaia di hacker etici partecipano al bug bounty creato per l’occasione, stimolati da una sana competizione a colpi di vulnerabilità scovate.
Contributo editoriale sviluppato in collaborazione con Unguess
