I supply chain attack collegati alla catena del valore dello sviluppo software stanno diventando sempre più insidiosi, anche e soprattutto perché molte aziende non hanno ancora ben chiaro come questo tipo di minacce si concretizzi. In generale difendersi dai supply chain attack non è comunque semplice, per due motivi principali.

Il primo è che la supply chain del software è potenzialmente enorme. Ci sono milioni di progetti open source che si scompongono ciascuno in un gran numero di componenti potenzialmente vulnerabili, aggiornati di frequente e scaricati da milioni di utenti più volte l'anno. Tanto per fare un esempio, a metà 2018 GitHub contava 85 milioni di repository consultati da 28 milioni di utenti.

Il secondo e più importante problema è che, dati proprio questi numeri, nessun repository può permettersi di verificare l'affidabilità dei progetti che ospita. Chiunque può caricare componenti "ostili" e provare a diffonderli: solo dopo che le vittime ne segnaleranno la pericolosità, chi gestisce il repository provvederà a fare le sue indagini e poi a cancellare il progetto.

Ma chi deve controllare?

Il problema di un controllo limitato non riguarda solo i componenti esplicitamente ostili. Anche quando viene scoperta una vulnerabilità in un componente software lecito, di norma la soluzione scelta è relativamente passiva. Chi gestisce il componente ne sviluppa una nuova versione sicura, la carica sul repository e si aspetta che gli utenti la scarichino.

Di per sé l'approccio non è sbagliato, ma rischia di essere insufficiente oggi che gli sviluppatori software sono obbligati a generare applicazioni sempre più rapidamente e più frequentemente. E che il software non è più una operazione di "scrittura" ma piuttosto di assemblaggio. Messe così le cose affidarsi all'aggiornamento da parte di milioni di sviluppatori è rischioso, specie quando la vulnerabilità in questione non è di quelle che finiscono subito sotto i riflettori. O peggio quando non è nemmeno catalogata nei vari database di vulnerabilità.

Tutto questo di fatto ribalta sugli sviluppatori e sulla loro azienda il compito di portare affidabilità alla propria supply chain software. Questo compito oggi è una esigenza imprescindibile, dettata non solo dal voler evitare le possibili vulnerabilità e i potenziali attacchi che comportano, ma anche dal fatto che le normative si stanno orientando verso una sempre maggiore responsabilizzazione di chi produce applicazioni. Il GDPR è la prima vera norma che impone il modello del security-by-design ma promette di non essere l'unica, a livello internazionale.

Quattro passi da seguire

I vari operatori del mondo della cyber security stanno affrontando il problema dei supply chain attack e ognuno dà i suoi consigli. Combinando e sintetizzando le loro raccomandazioni, se ne deriva una serie di possibili linee guida.

Capire la "gerarchia" di un progetto - I team di sviluppo e di controllo qualità devono avere chiaro quali framework e librerie si usano in un progetto, in quali versioni e da quali altri moduli dipendono a loro volta questi componenti. Idealmente, poi, bisogna tenere traccia di tutti i problemi di sicurezza collegati ai nodi di questa gerarchia di sviluppo.

Definire una policy per l'open source - Bisogna delimitare una sorta di "perimetro sicuro" per l'open source, definendo quali componenti sono accettabili in un progetto, quali certamente no e quali vanno valutati caso per caso. Una policy del genere può guardare a qualsiasi tipo di parametro, per la sicurezza di solito si valuta se uno specifico componente software è associato a segnalazioni di vulnerabilità (e quanto esse siano gravi). Dato che i componenti open source adottati possono essere molti e aggiornarsi di frequente, l'implementazione di queste policy deve inevitabilmente essere automatizzata.

Scegliere componenti recenti - Statisticamente un componente software recente è meno soggetto a vulnerabilità di uno più datato. Questo vale ovviamente per versioni diverse di uno stesso package, ma è un criterio da seguire anche quando si valutano componenti diversi che svolgono funzioni paragonabili.

Adottare un approccio DevSecOps - Sigle esoteriche a parte, ciò significa adottare un approccio di security-by-design nello sviluppo e implemenentare test automatici della sicurezza delle applicazioni sviluppate e dei loro componenti. I test si possono eseguire in vari punti di un flusso DevOps, non solo nella fase propriamente di test e assicurazione qualità.