Più di tre aziende su cinque sono state bersagliate da attacchi alla supply chain del software nel 2021. Le più colpite sono state le aziende tecnologiche, che sono preoccupate, ma c’è ancora molto lavoro da fare per prevenire gli attacchi. I dati sono stati collezionati da un sondaggio di Anchore che ha coinvolto 428 persone in ruoli di responsabilità nei settori IT, sicurezza e DevOps.

Il 55% degli intervistati prima del 9 dicembre (data della scoperta di Log4j) ha dichiarato di aver subito un attacco alla supply chain software. Dopo quella data, il numero è salito al 65%. Come accennato, quelle che risultano maggiormente colpite sono state le aziende tecnologiche, con una percentuale del 15%. Gli altri settori risultano influenzati solo per il 3%.

La motivazione alla base del dilagare di questo tipo di attacchi è nota: il ROI (Return On Investment) per gli attaccanti. Se un attaccante trova l’accesso a un prodotto software che viene usato da migliaia di persone, potenzialmente ha per le mani la chiave per attaccare migliaia di aziende. Investendo una sola volta nella realizzazione di un exploit funzionante.

È quindi chiaro che la sicurezza delle supply chain software dev’essere uno dei principali obiettivi delle aziende che ne fanno uso. È semplice a dirsi, ma è molto difficile da realizzarsi. Log4j ha reso ben chiara l’idea: ogni dipendenza software può ampliare la superficie di rischio, e con i container, le distribuzioni cloud native e i ritmi di sviluppo attuali, tenere traccia di centinaia, migliaia di dipendenze è un compito quasi impossibile.

Software Bills of Materials

Quasi, perché un modo per dire il vero ci sarebbe. È il famoso Software Bills of Materials (SBOM), che il Governo USA ha fatto diventare un requisito sine qua non per proporsi come fornitore per le agenzie federali statunitensi.

In estrema sintesi, lo SBOM consiste nella lista dettagliata e costantemente aggiornata di tutti i componenti software di un progetto, compresi quelli proprietari e quelli open source. Questo inventario digitale dovrebbe tenere traccia della provenienza di ogni blocco di codice.

L’utilità di questo strumento è fin troppo ovvia: nel momento in cui emerge una falla come Log4j, basta consultare lo SBOM per sapere esattamente quali dei programmi in uso in azienda devono essere aggiornati con urgenza. Nessuno escluso. Questo consente di avere sempre chiara la situazione, di poter intervenire tempestivamente e in maniera mirata. Un elenco certosino e aggiornato fa la differenza fra un tempo di patching di mesi e uno di ore.

Anchore però sottolinea un problema diffuso. Meno di un terzo degli intervistati segue le best practice SBOM; solo il 18% dispone di uno SBOM completo per tutte le proprie applicazioni. Il problema non è la pigrizia degli addetti. È una questione di tempo e risorse. Per generare e aggiornare automaticamente gli elenchi occorrono strumenti adeguati. Tali strumenti oggi non sono standardizzati, e non si conoscono nel dettaglio i requisiti che verranno fissati nello standard di riferimento.

Gli sviluppatori potrebbero occuparsene, ma dovrebbero investire il tempo che non hanno per stilare liste complesse, lunghe, faticose. Questi elementi fanno dedurre che difficilmente da qui a una manciata di mesi tutti avranno messo nero su bianco l’elenco completo dei componenti software usati in azienda.

DevSecOps

Ancora più difficile è la questione DevSecOps, ossia l’adozione di un modello di sviluppo sicuro delle applicazioni, in cui la security è integrata direttamente in fase di sviluppo, e non aggiunta a posteriori come nel modello DevOps. Se ne parla da tempo, dopo l’attacco a SolarWinds il dibattito si è intensificato. Ma i risultati concreti sono insoddisfacenti nella maggioranza dei casi.

Certo, DevSecOps sarebbe la soluzione ideale, ma è complessa da attuarsi in quanto richiede un cambiamento di approccio e una sintonia fra diversi team che tipicamente non comunicano attivamente, in primis quelli di sviluppo e di IT a cui fa capo la security. Quello di DevSecOps è un concetto che vede le sue basi nella presa di coscienza da parte di tutti che la sicurezza è una responsabilità condivisa. Ma che si infrange immancabilmente sullo scoglio della comunicazione fra dipartimenti e sul diverso approccio ai problemi da parte degli stessi.

Team di sviluppo e IT sono storicamente contrapposti e arroccati su posizioni distanti anni luce. Gli sviluppatori prioritizzano i tempi di sviluppo e percepiscono la sicurezza come un ostacolo, l’IT reputa di prioritaria la sicurezza, anche a costo di rallentare lo sviluppo. Come testimonia una ricerca recente, il 52% degli sviluppatori reputa che le politiche di sicurezza soffochino l’innovazione.

Di questo passo non si va da nessuna parte. E a farne le spese sono le aziende stesse in cui lavorano entrambi i contendenti. Un’alleanza fra le due parti, o meglio una mediazione condivisa, sarebbe auspicabile per il bene di entrambe, ma la strada per ottenerla spesso appare ancora lunga. Il guaio è che passa necessariamente per un cambio di paradigma nella concezione stessa di sicurezza e nell’approccio a costruire qualcosa di solido dalle fondamenta, non come accessorio aggiunto.