Come dimostrano le ricadute delle vulnerabilità di Apache Log4J all’inizio di quest’anno, i maggiori rischi nel software aziendale di oggi non sono necessariamente dovuti a codice non sicuro scritto direttamente dai team di sviluppo software interni. I difetti dei componenti, delle librerie e di altro codice open source che costituiscono la maggior parte delle basi di codice software di oggi rappresentano infatti la parte subacquea dell’iceberg dell’insicurezza.

La verità è che gran parte del software aziendale e delle applicazioni personalizzate prodotte dai team DevOps e dai gruppi di ingegneria del software non è effettivamente codificato dai loro sviluppatori. Il software moderno oggi è modulare. Gli sviluppatori utilizzano quella che viene chiamata architettura di microservizi per creare nuove applicazioni costruendole in modo molto simile a una casa Lego, utilizzando cioè blocchi costituiti da codice prefabbricato. Invece di reinventare la ruota ogni volta che hanno bisogno della loro applicazione per eseguire una funzione comune, gli sviluppatori frugano nella loro proverbiale “scatola di blocchi” per trovare quello giusto che farà ciò di cui hanno bisogno senza troppi problemi.

Quella scatola è l’odierna supply chain del software in continua espansione, una fonte di codice a volte molto informale proveniente dai milioni di repository GitHub e progetti open source che circolano online oggi. È costituita da componenti e librerie utilizzati in una miriade di applicazioni e nell’infrastruttura di sviluppo utilizzata per costruire moderne pipeline di sviluppo.

Naturalmente, i programmi forniti da questa catena di approvvigionamento non sono realmente dei mattoni e non sempre si incastrano perfettamente; è per questo che gli sviluppatori creano un codice personalizzato per incollare insieme tutti quei pezzi. In effetti, molti spesso trasformano quelle creazioni in progetti ancora più open source per consentire ad altri di risolvere problemi simili. Questo è uno dei motivi per cui la supply chain del software continua a crescere.

Applicazioni create con codice di terze parti

Un’applicazione moderna è composta principalmente da codice di terze parti. Secondo Forrester, la percentuale di codice open source che costituisce la base di codice di un’applicazione media è aumentata dal 36% nel 2015 al 75% nel 2020.

È un modo più rapido e scalabile per sviluppare rapidamente ma, come tutte le innovazioni tecnologiche, comporta un rischio informatico aggiuntivo a meno che non venga prestata la dovuta attenzione. A rendere le cose ancora più complicate è il fatto che i difetti sono spesso nidificati insieme poiché progetti diversi possono dipendere da altri nella catena di approvvigionamento. A volte i difetti possono anche essere aggiunti di proposito da aggressori che seminano intenzionalmente delle vulnerabilità nel software open source.

Le vulnerabilità introdotte dalla supply chain del software possono essere come mine nascoste di sicurezza informatica nel software aziendale, in particolare quando le organizzazioni non fanno nulla per governare formalmente il modo in cui i loro sviluppatori utilizzano la catena di fornitura del software. Molte organizzazioni a malapena tracciano (e ancor meno controllano o gestiscono) tipi di componenti, librerie e strumenti di sviluppo che producono il codice utilizzato dai loro sviluppatori. Secondo uno studio pubblicato dalla Linux Foundation, meno della metà delle organizzazioni utilizza una distinta base del software (SBOM) che tiene traccia esattamente di ciò che entra nelle loro applicazioni dalla supply chain del software.

Di seguito è riportato un elenco di strumenti che aiutano a raggiungere questo obiettivo, con una forte enfasi sugli strumenti di analisi della composizione del software (SCA) che si concentrano specificamente sullo sviluppo di SBOM, aumentando la visibilità su ciò che entra nel software e risolvendo i difetti nei componenti che sono gli elementi costitutivi del software oggi.

I migliori strumenti per la sicurezza della supply chain del software

Contrast Security

Conosciuto soprattutto per la sua tecnologia Interactive Application Security Testing (IAST) che rileva le vulnerabilità nelle applicazioni tramite un agente in esecuzione sul server delle applicazioni, Contrast Security fornisce funzionalità SCA come parte di una serie completa di test nella sua piattaforma aperta, che esegue anche dynamic application security testing (DAST), static application security testing (SAST), runtime application scanning protection (RASP) e controlli di sicurezza serverless sull’infrastruttura AWS Lambda.

low-code

Gli strumenti possono non solo generare una SBOM, ma anche contestualizzare i difetti tra i vari ingredienti che compongono un’applicazione visualizzando l’architettura dell’applicazione, gli alberi del codice e le informazioni sul flusso di messaggi per aiutare nella correzione della modellazione delle minacce. La governance open source è incorporata nei moderni flussi di lavoro e strumenti di sviluppo e l’obiettivo finale di Contrast sta nel colmare il divario tra sviluppatori e team di sicurezza, rendendolo un attore importante nel mercato DevSecOps.

ShiftLeft

ShiftLeft è progettato per adattarsi al flusso di lavoro di sviluppo dei team DevOps lungimiranti. Il valore fondamentale è riunire SCA e SAST in un’unica scansione che viene eseguita quando uno sviluppatore effettua una richiesta pull. La tecnologia utilizza una tecnica che l’azienda chiama Code Property Graph (CPG) per mappare le dipendenze e i flussi di dati attraverso codice personalizzato, librerie open source, SDK e API, cercando non solo i difetti nell’intera applicazione (compresi i suoi componenti open source), ma anche punti deboli logici dell’app. I difetti della supply chain hanno la priorità in base alla suscettibilità agli attacchi utilizzando un indice di “raggiungibilità” inserito nella SBOM.

Snyk

Snyk è un set di strumenti cloud-native, incentrato sugli sviluppatori, creato appositamente per DevSecOps e shop di sviluppo cloud-native. Meglio conosciuto per le sue capacità di scansione della sicurezza dei container e SCA, Snyk offre anche test di vulnerabilità SAST e API. Come ha spiegato Gartner, la sua combinazione di offerte attraverso l’infrastruttura come sicurezza del codice, sicurezza dei container e sicurezza delle applicazioni è rappresentativa del fatto che “i livelli delle applicazioni e dell’infrastruttura si confondono sempre più”. Di solito viene acquistato dal lato degli sviluppatori, ma vale la pena dare un’occhiata ai CSO e al personale di sicurezza che cercano di passare a un modello democratizzato di test di sicurezza e riparazione gestiti dagli sviluppatori.

Sonatype Nexus

Tra le offerte più longeve nel mercato SCA, Sonatype si definiva come un’azienda di “sicurezza della supply chain del software” molto prima che il termine si facesse strada tra i titoli delle conferenze sulla sicurezza e delle sessioni webinar. Il cuore della piattaforma Sonatype Nexus sono le sue capacità per la creazione di SBOM dettagliate e la gestione delle policy. Secondo gli analisti di Forrester le policy sono il punto di forza di Sonatype, tra policy pronte all’uso che si allineano a una gamma di standard e un motore di policy che consente agli utenti di creare e assegnare policy a determinati tipi di applicazioni. I criteri possono essere applicati non solo per ciò che entra nel codice, ma anche per gestire la sicurezza e la configurazione dell’infrastruttura circostante come codice e container utilizzati per sviluppare e distribuire applicazioni.

Anche la visualizzazione della cronologia dei componenti da parte di Nexus e il servizio clienti di Sonatype sono indicati dagli analisti come altri punti di forza. L’anno scorso Sonatype ha inoltre acquisito MuseDev, mossa che l’ha aiutata a sviluppare le capacità di Sonatype Lift, che forniscono analisi della qualità del codice adatte agli sviluppatori durante la revisione del codice.

Synopsys Black Duck

Lo strumento Black Duck SCA di Synopsys esegue quattro tipi di analisi (dipendenza, codeprint, binario e snippet) per tracciare e gestire i componenti utilizzati all’interno del software di un’organizzazione. Synopsys ha recentemente migliorato le capacità di creazione SBOM di Black Duck includendo BLANK, strumento che oltre a creare distinte base (BOM – Bills of Materials), esegue anche la gestione automatizzata delle policy.

Black Duck fa parte del più ampio portafoglio di strumenti AppSec offerto da Synopsys, che Gartner ha nominato leader nel suo Magic Quadrant per i test di sicurezza delle applicazioni. Il modello di piattaforma aperta utilizzato per fornire SCA insieme a DAST, SAST, test di penetrazione, fuzzing e una gamma di altre funzionalità di test è una proposta di valore chiave. “Tutto ciò rende Synopsys una valida soluzione per le organizzazioni con sviluppo multiteam complesso che utilizzano un mix di stili di sviluppo e tecnologie di programmazione”, afferma Gartner.

Veracode

Veracode negli ultimi anni ha investito ingenti somme in SCA. “La roadmap di Veracode si concentra sull’unificazione delle funzionalità SAST e SCA nell’ambiente di sviluppo e sul miglioramento delle capacità di sicurezza di container e IaC (Infrastructure as Code)”, spiegano gli analisti di Forrester. I punti salienti di Veracode sono i suoi report di riparazione e i suoi diagrammi delle dipendenze. 

WhiteSource Software 

Il punto forte degli strumenti SCA di WhiteSource Software è la risoluzione dei problemi di sicurezza dei componenti a misura di sviluppatore, inclusi avvisi e riparazione di componenti scaduti e dannosi. “La leadership di WhiteSource si concentra sulla correzione e sulla definizione delle priorità”, hanno scritto gli analisti di Forrester, che considerano questo fornitore un leader in ambito SCA.

“WhiteSource offre funzionalità differenzianti, incluso un plug-in del browser per evitare componenti problematici e rimuovere le vulnerabilità per migliorare l’esperienza degli sviluppatori”. Un punto debole di WhiteSource, che ha lanciato una soluzione SAST all’inizio di quest’anno, è invece la sua mancanza di policy pronte all’uso.