Uno dei motivi per cui l’open source è popolare nelle aziende è che fornisce “blocchi” di costruzione ben collaudati che possono accelerare la creazione di applicazioni e servizi sofisticati. Ma i componenti software di terze parti e la praticità di pacchetti e container comportano anche dei rischi. Gli attacchi alla supply chain del software stanno diventando così diffusi che Gartner li ha elencati come la seconda più grande minaccia per il 2022. Entro il 2025, la società di ricerca prevede che il 45% delle organizzazioni a livello globale avrà subito uno o più attacchi alla supply chain del software; questi includono attacchi tramite vulnerabilità in componenti software ampiamente utilizzati come Log4j, attacchi contro la pipeline di compilazione (SolarWinds, Kaseya e Codecov) o hacker che compromettono i repository dei pacchetti stessi.

“Gli aggressori hanno spostato la priorità dagli ambienti di produzione alle supply chain del software perché queste ultime sono l’anello più debole” spiega Lior Levy, CEO di Cycode. “Finché le supply chain del software rimangono obiettivi relativamente facili, gli attacchi a esse aumenteranno”. I recenti incidenti di alto profilo sono stati un campanello d’allarme per l’industria dello sviluppo software, afferma Rani Osnat, vicepresidente senior della strategia di Aqua Security. “Abbiamo scoperto decenni di opacità e mancanza di trasparenza ed è per questo che è un grosso problema”.

Diversi studi su codice open source mostrano che le vulnerabilità e i componenti obsoleti o abbandonati sono comuni: l’81% delle basi di codice presentava almeno una vulnerabilità, il 50% aveva più di una vulnerabilità ad alto rischio e l’88% utilizzava componenti che non erano l’ultima versione o non avevano avuto nuovi sviluppi in due anni. È improbabile comunque che questi problemi intacchino la popolarità dell’open source e anche il software e i servizi commerciali sono vulnerabili. Quando LastPass è stato attaccato, non ha perso i dati dei clienti, ma una parte non autorizzata è stata in grado di visualizzare e scaricare parte del suo codice sorgente, il che potrebbe rendere più facile attaccare gli utenti del gestore di password in futuro.

La minaccia del “codice ombra”

Proprio come i team di sicurezza difendono le loro reti come se fossero già state violate, i CIO devono presumere che tutto il codice, interno o esterno, e persino gli ambienti e gli strumenti di sviluppo utilizzati dai loro sviluppatori siano già stati compromessi e mettere in atto politiche per proteggere e ridurre al minimo l’impatto degli attacchi contro le loro supply chain del software. In effetti, Osnat suggerisce ai CIO di pensare a questo “codice ombra” nello stesso modo in cui pensano allo shadow IT. “Questo codice ombra deve essere considerato non solo come un problema di sicurezza, ma come qualcosa che va in profondità nel modo in cui si ottiene il software, sia esso open source o commerciale: come lo si porta nel proprio ambiente, come lo si aggiorna, che tipo di controlli si desidera avere in atto e che tipo di controlli si desidera richiedere ai fornitori”.

supply chain del software

Trasparenza: verso una distinta base software

Le supply chain fisiche utilizzano già etichette, elenchi di ingredienti, schede di dati di sicurezza e distinte base, in modo che le autorità di regolamentazione e i consumatori sappiano cosa finisce nei prodotti. Nuove iniziative mirano ad applicare approcci simili al software, aiutando le organizzazioni a comprendere la rete di dipendenze e la superficie di attacco del loro processo di sviluppo software.

L’ordine esecutivo 14028 della Casa Bianca sulla sicurezza della supply chain del software richiede ai fornitori di software che forniscono il governo federale di fornire una distinta base software (SBOM) e utilizzare la lista di controllo di sicurezza dei livelli della supply chain per gli artefatti software (SLSA) per prevenire manomissioni. Per questo motivo, “stiamo vedendo molte aziende guardare molto più seriamente alla loro supply chain del software”, afferma l’analista senior di Forrester Janet Worthington. “Tutte le aziende oggi producono e consumano software e stiamo vedendo sempre più produttori chiederci come possono produrre software che sia sicuro e che possono attestare con una distinta base software.”

Esistono numerosi progetti intersettoriali, tra cui l’iniziativa nazionale del NIST per il miglioramento della sicurezza informatica nelle supply chain (NIICS) e l’iniziativa SCITT (Supply Chain Integrity, Transparency, and Trust) di Microsoft, nonché il Supply Chain Integrity Working Group. Un recente sondaggio della Linux Foundation ha rilevato che la consapevolezza nei confronti della SBOM è elevata, con il 47% dei fornitori IT, dei fornitori di servizi e delle industrie regolamentate che oggi utilizzano SBOM e l’88% che prevede di utilizzarla nel 2023.

Le distinte base software saranno molto utili per le organizzazioni che dispongono già di gestione delle risorse per componenti software e API. “Le persone che oggi dispongono di solidi processi di sviluppo software trovano più facile inserire strumenti in grado di generare una distinta base software”, afferma Worthington. Le distinte base software possono essere create dal sistema di compilazione o possono essere generate da strumenti di analisi della composizione del software. Perché tutto ciò sia utile, sono necessarie politiche chiare su come i team di sviluppatori acquisiscono software open source, afferma Dan Lorenc, CEO di Chainguard. “Come fanno gli sviluppatori a sapere quali sono le policy della loro azienda per ciò che è considerato ‘sicuro’ e come fanno a sapere che l’open source che stanno acquisendo, e che costituisce la grande maggioranza di tutto il software utilizzato dagli sviluppatori in questi giorni, non sia manomesso?”

Lorenc indica il progetto open source Sigstore che JavaScript, Java, Kubernetes e Python utilizzano per stabilire la provenienza dei pacchetti software. “Sigstore è per l’integrità del software un po’ quello che i certificati sono per i siti web; fondamentalmente stabilisce un sistema di verifica della fiducia. Penso che un CIO dovrebbe iniziare formando i propri team di sviluppatori su questi passaggi fondamentali di utilizzo di approcci standard di settore emergenti, bloccando i sistemi di compilazione e, infine, creando un metodo ripetibile per verificare l’affidabilità degli artefatti software prima di portarli nell’ambiente”.

Dare il proprio contributo

Che si tratti di componenti, API o funzioni serverless, la maggior parte delle organizzazioni sottovaluta ciò che sta utilizzando fino a quando non vengono eseguiti inventari di routine, sottolinea Worthington. “Scoprono allora che alcune di queste API non utilizzano metodi di autenticazione adeguati, non sono scritte nel modo in cui si aspettavano o forse alcune di esse sono persino deprecate”. Al di là delle vulnerabilità, valutare il supporto della community dietro un pacchetto è importante quanto capire cosa fa il codice, dal momento che non tutti i manutentori vogliono che il loro codice venga trattato come una risorsa critica. “Non tutti gli open source sono uguali”, avverte Worthington.

“L’open source può essere scaricabile gratuitamente, ma il suo utilizzo non è gratuito. L’utilizzo da parte vostra significa infatti che siete responsabili della posizione di sicurezza che sta dietro a un software open source visto che questo è nella vostra supply chain. Dovete sempre e comunque contribuire ad esso: i vostri sviluppatori devono partecipare alla correzione delle vulnerabilità“. Worthington suggerisce inoltre che le organizzazioni dovrebbero essere pronte a contribuire anche con risorse e fondi a progetti open source o a iniziative che li supportano. 

supply chain analytics

Non pensate però a questo solo come a una spesa, ma anche come un’opportunità per comprendere meglio i componenti da cui dipendete. “Questo approccio aiuta anche a fidelizzare gli sviluppatori, a farli sentire parte della comunità e a spingerli a contribuire con le loro capacità.” Ricordate che le vulnerabilità possono essere trovate ovunque nel vostro stack tecnologico inclusi i mainframe, che eseguono sempre più Linux e software open source come parte del carico di lavoro ma che spesso mancano dei processi e dei framework di sicurezza diventati invece comuni in altri ambienti.

Protezione della pipeline

Anche la protezione della pipeline di distribuzione del software è importante. Il Secure Software Development Framework (SSDF) del NIST è un buon punto di partenza. Questo framework copre infatti le best practice a vari livelli di maturità a partire da un semplice sistema di compilazione, per poi proseguire con i registri e metadati per il controllo e la risposta agli incidenti fino a una pipeline di compilazione completamente protetta. Sono utili anche il white paper sulle best practice della supply chain del CNCF, le linee guida di Gartner sulla mitigazione dei rischi per la sicurezza della supply chain del software e l’OSS Secure Supply Chain Framework di Microsoft, che include sia processi, sia strumenti.

È importante notare, tuttavia, che la semplice attivazione di strumenti di scansione automatica destinati a trovare codice dannoso può produrre troppi falsi positivi per essere davvero utile. E sebbene i sistemi di controllo delle versioni come BitBucket, GitHub, GitLab e altri includano funzionalità di sicurezza e protezione dell’accesso (controlli delle policy di accesso sempre più granulari, protezione delle filiali, firma del codice, richiesta di MFA per tutti i collaboratori e scansione di credenziali), spesso devono essere abilitati in modo esplicito.

Inoltre, progetti come Factory for Repeatable Secure Creation of Artifacts (FRSCA) che mirano a proteggere le pipeline di compilazione implementando SLSA in un singolo stack non sono ancora pronti per la produzione, ma in futuro (ed è bene che i CIO lo sappiano) i sistemi di compilazione includeranno sempre più queste e altre pratiche.

Infatti, mentre le distinte base software sono solo una parte della risposta, anche gli strumenti per crearli e lavorarci stanno maturando, così come i processi per richiederli e consumarli. I contratti devono specificare non solo che volete le distinte base software, ma anche quanto spesso ci si aspetta che vengano aggiornate e se includeranno segnalazioni di vulnerabilità e notifiche. “Se viene trovata una nuova importante vulnerabilità come Log4j, il fornitore me lo dirà o dovrò cercarmela da solo?”, si chiede Wothington.

Le organizzazioni avranno anche bisogno di strumenti per leggere le distinte base software e mettere in atto processi per intraprendere azioni su ciò che questi strumenti trovano. “Ho bisogno di uno strumento che possa dirmi quali sono le vulnerabilità note nelle distinte e quali sono le implicazioni della licenza”.

I CIO dovrebbero anche tenere presente che una distinta base software “è un fattore abilitante, ma in realtà non risolve nulla in termini di protezione della supply chain. Aiuta se mai a far fronte agli incidenti che potrebbero capitarvi”, afferma Osnat, che è ottimista sia sulla velocità di risposta del settore, sia sull’ampia collaborazione in corso riguardo gli standard per le distinte base software e l’attestazione del codice che contribuirà a rendere interoperabili gli strumenti. Ciò potrebbe portare agli stessi miglioramenti negli standard di trasparenza e reporting in tutto il settore forniti dallo standard SOC 2.

Detto questo, i CIO non devono aspettare nuovi standard o nuovi strumenti per iniziare a rendere la sicurezza parte del ruolo di sviluppatore. “Iniziate mettendo nella stessa stanza il vostro CISO e il vostro ingegnere capo per capire sia qual è il modello giusto perché la sicurezza nello sviluppo funzioni, sia il modo in cui avverrà tale trasformazione”, conclude Osnat.