La supply chain e le sue vulnerabilità oggi sono al centro dell’attenzione perché spesso sfruttate per attacchi di grande scala. Non sorprende quindi che anche nel mondo del software le minacce siano consistenti. La prima volta che abbiamo sentito parlare pubblicamente di una vulnerabilità molto pervasiva e problematica nella catena di fornitura del software è stato con log4j, un’applicazione di logging estremamente diffusa, la cui vulnerabilità è stata relativamente facile da sfruttare per consentire l’esecuzione di codice remoto, e che ha quindi avuto un impatto disastroso e portato a una corsa globale per mitigare la vulnerabilità.
Più di recente, è stata la volta di Spring4Shell, una vulnerabilità critica nel popolare framework JavaSpring, che ha causato il caos per le aziende che si sono trovate ad affrontare la minaccia.
Se prendiamo in considerazione i risultati dell’ultimo rapporto di Sonatype sullo stato della catena di fornitura del software, potremo trovare statistiche in grado di spaventare qualsiasi tecnologo attento alla sicurezza, indipendentemente dal suo ruolo. In particolare, a partire dalla considerazione che oggi sono disponibili 37 milioni di versioni di componenti OSS, è da notare che il 29% dei progetti più diffusi contiene almeno una vulnerabilità di sicurezza nota e che i cyberattacchi rivolti ai fornitori open source crescono con un ritmo del 650% su base annua. Questi dati sono particolarmente preoccupanti perché il rapporto ha stabilito che “Un’applicazione moderna contiene mediamente 128 dipendenze open source“.
A tal proposito, anche nello State of Application Strategy del 2022 recentemente pubblicato da F5, troviamo statistiche degne di nota. In particolare, le applicazioni moderne (container-native e mobile) comprendono in media il 33% del portafoglio di applicazioni aziendali e le aziende di tutti i settori gestiscono in media un portafoglio di circa 200 applicazioni.
Quindi, facendo alcuni calcoli (33% di 200 applicazioni) possiamo dire che un’azienda ha in media 66 applicazioni moderne nel suo portafoglio e utilizzando i risultati di Sonatype sulle dipendenze open source, questo significa che potrebbe avere l’onere di proteggere 8.448 diverse dipendenze open source. Ora, c’è quasi certamente una sovrapposizione perché le applicazioni container-native condividono quasi sempre lo stesso ambiente di organizzazione dei container (Kubernetes è il principale protagonista in questo momento) e quindi l’onere potrebbe essere inferiore in termini di dipendenze specifiche, ma non nel senso che ogni istanza debba essere aggiornata in caso di vulnerabilità.
Ritengo, quindi, che i dati esaminati confermino pienamente come garantire la sicurezza della supply chain del software oggi sia un’impresa significativa, date le dimensioni dei portafogli di applicazioni e le molteplici dipendenze open source.
Un passaggio estremamente positivo è stata l’introduzione da parte della piattaforma di hosting web GitHub di nuove funzionalità per la sicurezza della Supply Chain del software che consentono di “trovare e bloccare le vulnerabilità che attualmente vengono visualizzate solo nella rich diff di una pull request”. In altre parole, si integrano nella pipeline CI/CD e scansionano, in tempo reale, le vulnerabilità note.
Non si tratta di qualcosa di totalmente rivoluzionario; i DevSecOps stanno guidando questo tipo di sviluppo della sicurezza “shift left” da anni ormai e la maggior parte delle pipeline CI/CD, indipendentemente dagli strumenti adottati, è in grado di eseguire scansioni di sicurezza sul codice. Non tutte, tuttavia, integrano la capacità di scansionare le vulnerabilità note che potrebbero essere profondamente nascoste nelle dipendenze o il risultato di un errore logico non facile da rilevare.
La conclusione è quindi semplice: è necessario includere il più possibile la sicurezza nella pipeline CI/CD, per eliminare le vulnerabilità e gli errori che possono essere rilevati in un secondo momento.
Il motivo per cui ho evidenziato il problema dell’attuale software supply chain è però un altro. Un elemento a mio avviso estremamente critico è che la situazione è destinata a peggiorare man mano che le organizzazioni modernizzano le attività operative con approcci di site reliability engineering (SRE). Questo perché, nella sua essenza, le pratiche di ingegneria del software alle operazioni IT SRE dipendono dall’automazione che, a sua volta, dipende da software e script, molti dei quali sono open source.
In effetti, molti degli strumenti open source utilizzati dai DevOps saranno utilizzati anche dagli SRE. Volendo semplificare i ruoli e le relazioni, i Site Reliability Engineer sono i DevOps della produzione. Mentre i professionisti DevOps si concentrano in genere sulla pipeline di creazione e rilascio del software, i SRE si concentrano sulla pipeline delle operazioni software. Questo comprende non solo le applicazioni, ma anche la sicurezza delle applicazioni e i servizi di distribuzione, nonché le piattaforme e gli ambienti (come core, cloud ed edge). Il campo d’azione del personale SRE si estende a tutto lo stack IT, rendendo il loro compito molto più difficile quando si tratta di proteggere la catena di fornitura del software.
La sicurezza della supply chain del software dovrebbe essere una preoccupazione per tutte le organizzazioni, perché ha un impatto sull’intero ciclo di vita dell’applicazione, dallo sviluppo alla creazione, al rilascio, alla distribuzione e al funzionamento. Dovrebbe rappresentare una preoccupazione per tutte le organizzazioni mentre affrontano il loro percorso di trasformazione digitale.
Credo, infatti, che sia in atto un cambiamento significativo nelle aziende di tutto il mondo, che ha un impatto sul fondamento stesso dell’organizzazione: l’architettura aziendale. Spesso quest’ultima è stata creata decenni fa, sulla base di strutture sviluppate con la premessa che le risorse fossero fisse e inflessibili e che il centro dati fosse il fulcro dell’universo aziendale.
Tutto questo non è più vero e il business è profondamente cambiato.
L’azienda, sempre più digitale, si affida oggi a processi guidati dai dati e non può essere rappresentata adeguatamente da un’architettura progettata per un’azienda fisica con processi guidati dall’uomo. L’architettura aziendale deve quindi essere modernizzata e, nel farlo, è necessario incorporare nuovi domini, come quello delle operazioni SRE.
La nostra ricerca sulla sicurezza delle applicazioni ha rilevato che il 37% delle organizzazioni ha già abbracciato le operazioni SRE per modernizzare le applicazioni e le operazioni, e un altro 40% sta pianificando di farlo nei prossimi 12 mesi.
In sintesi, la buona notizia è che l’approccio SRE è sempre più adottato e rappresenterà una nuova best practice per le organizzazioni che consentirà loro di stabilire nuovi modi di operare, compreso l’integrazione fin dal principio della sicurezza nella catena di approvvigionamento del software.
