Logo ImpresaCity.it

Come ci si difende dai supply chain attack

Tenere sotto controllo la supply chain dello sviluppo software non è semplice, ma alcune linee guida possono aiutare

f.p.

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.
office 1209640 1280

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.
sviluppo lab azure devops

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à.

Se questo articolo ti è piaciuto e vuoi rimanere sempre informato con le notizie di ImpresaCity.it iscriviti alla nostra Newsletter gratuita.
Se vuoi ricevere le notifiche delle notizie più importanti della giornata iscriviti al canale Telegram di ImpresaCity al link: t.me/impresacity
Pubblicato il: 19/10/2018

Speciali

Download

Gestire la sicurezza alla convergenza tra IT e OT

Speciali

La sanità alla prova della trasformazione digitale