La velocità con cui vengono scoperte nuove vulnerabilità è in costante aumento. Attualmente si attesta ad una media di 15,000 CVE all'anno. Il 2022 si distingue con oltre 26,000 nuovi CVE segnalati. Ovviamente, non tutte le vulnerabilità sono rilevanti per il tuo software. Per capire se una particolare vulnerabilità costituisce un problema, devi prima capire se stai utilizzando la libreria o il prodotto che contiene la vulnerabilità, quindi capire se stai utilizzando la versione e il modulo problematici di quella libreria. Infine, devi consultare il tuo team di sviluppo per vedere se tale vulnerabilità è rilevante per il tuo particolare prodotto e il modo in cui hai utilizzato quella libreria o prodotto vulnerabile.
Il processo per capire tutto questo non è semplice e può richiedere molto tempo. Lo stima Tom Alrich, noto esperto di sicurezza informatica circa il 95% di tutti i CVE presenti in un particolare prodotto software non sono sfruttabili. Ma se sei un utente finale o un'azienda in procinto di integrare software di terze parti nel proprio sistema, come puoi identificare il 5% problematico in modo da poter richiedere una riparazione o un'applicazione di patch adeguata?
Da qui nasce l'idea Entra in gioco Vulnerability Exploitability Exchange (VEX).. Lo scopo di VEX, come definito da guida dalla National Telecommunications and Information Administration (NTIA) degli Stati Uniti nel 2021, è "fornire agli utenti (ad esempio, operatori, sviluppatori e fornitori di servizi) informazioni aggiuntive sull'eventuale impatto di un prodotto da una specifica vulnerabilità in un componente incluso e, se interessato , se vi sono azioni consigliate per porre rimedio."
In questo momento probabilmente starai pensando: come posso ottenere questi documenti VEX e iniziare a controllare i miei componenti? Ebbene, la realtà dell'uso dei VEX è, come al solito, complicata.
Scopri lo scopo di VEX
In parole povere, VEX dovrebbe rispondere in modo rapido e semplice alla domanda "la mia versione di questo software è sfruttabile a questo scopo". vulnerabilità?'.
La risposta a questa domanda dovrebbe essere una delle quattro opzioni principali:
- Non affetto: Non è richiesta alcuna riparazione in merito a questa vulnerabilità.
- Ricercato: Si consigliano azioni per correggere o affrontare questa vulnerabilità.
- Fisso: Queste versioni del prodotto contengono una correzione per la vulnerabilità.
- Sotto investigazione: Non è ancora noto se queste versioni del prodotto siano interessate da questa vulnerabilità. Un aggiornamento verrà fornito in una versione successiva.
Poiché VEX dovrebbe essere sia leggibile dalla macchina che generato dalla macchina, l'idea è di avere un database ricercabile di questi documenti da qualche parte in modo che qualsiasi parte interessata possa interrogarlo e ottenere la risposta necessaria.
Poiché il presupposto è che il 95% delle vulnerabilità non sono sfruttabili in un dato prodotto software, questo sistema ha lo scopo di ridurre gli enormi elenchi di vulnerabilità trovate per ciascun prodotto solo a quelle che l'utente dovrebbe tenere d'occhio o richiedere soluzioni o patch. per.
Ci sono una serie di fatti interessanti sulla storia di VEX
Nel 2020, NTIA (l'Amministrazione nazionale delle telecomunicazioni e dell'informazione degli Stati Uniti) ha iniziato a discutere l'idea di VEX come strumento di accompagnamento al SBO (Distinta materiali del software). Nel settembre 2021, la NTIA ha pubblicato un'introduzione di una pagina e una spiegazione di ciò che VEX dovrebbe fare.
Successivamente, lo sforzo di perfezionare i requisiti del nuovo formato consultivo si è spostato sotto l’egida della CISA – l’Agenzia statunitense per la sicurezza informatica e le infrastrutture, che ha pubblicato il proprio documento all'inizio del 2022 entreremo un po' più nel dettaglio e in alcuni casi d'uso in cui il documento VEX avrebbe dovuto aiutare. Il documento, una bozza, definiva i campi minimi richiesti del documento VEX nello stesso modo in cui NTIA definiva i campi minimi richiesti dell'SBOM.
Da allora ci sono stati 2 tentativi principali di creare effettivamente un formato di documentazione VEX leggibile dalla macchina:
- Il Marketplace per le Quadro consultivo comune sulla sicurezza (CSAF) è stato il primo formato disponibile. Questo formato è stato rilasciato alla fine del 2022 da OASIS Open, un'organizzazione no-profit internazionale dedicata alla produzione di standard open source per la sicurezza informatica, blockchain, IoT e altre aree.
- Ciclone DX, un formato standardizzato per SBOM lanciato da OWASP (Open Web Application Security Project), che è stato adattato per creare anche documenti VEX.
CSAF è un formato completo ma per utilizzarlo effettivamente con successo è necessario includere più campi e molte metainformazioni rendendo improbabile un'effettiva adozione. L'iniziativa CyclonDX VEX è molto più snella, quindi quando si considera quale standard VEX utilizzare la maggior parte probabilmente andrebbe con il formato CyclonDX.
Perché VEX ha raggiunto un ostacolo: scoprire i problemi che ne sabotano il successo
VEX è una buona idea e potrebbe fornire la preziosa capacità di verificare rapidamente se una particolare vulnerabilità è effettivamente sfruttabile in un particolare prodotto software.
Ci sono diversi problemi, tuttavia, che finora ne stanno ostacolando l’attuazione:
- Responsabilità di archiviazione: chi dovrebbe essere responsabile dell'archiviazione dei documenti VEX richiesti? Sono i produttori di software? Società di sicurezza di terze parti o organizzazioni no-profit? Un'agenzia governativa? Cosa accadrebbe se più fonti fornissero informazioni contraddittorie?
- Database VEX: chi o cosa dovrebbe salvare e classificare le informazioni VEX? Supponendo che alcuni documenti descrivano problemi sfruttabili nel software, non c'è il pericolo che le informazioni cadano nelle mani sbagliate (dannose)?
- I formati attuali non risolvono adeguatamente la questione delle versioni e ancor meno il problema del controllo delle versioni combinato.
Le versioni combinate di software/pacchetti si riferiscono alla pratica di raggruppare più pacchetti o componenti software in un unico rilascio o pacchetto di installazione.
Quando si tratta di applicare patch alle vulnerabilità, le versioni combinate di software/pacchetti possono sia aiutare che ostacolare il processo. Da un lato, disporre di un unico pacchetto di installazione che includa tutti i componenti necessari può semplificare il processo di identificazione e correzione delle vulnerabilità. Invece di dover identificare manualmente e applicare patch a ogni singolo componente, puoi semplicemente applicare la patch all'intero pacchetto.
Tuttavia, il rovescio della medaglia è che se un componente all’interno del pacchetto è vulnerabile, l’intero software è vulnerabile. Ciò significa che anche se alcuni componenti all'interno del pacchetto sono stati patchati, il pacchetto complessivo potrebbe essere comunque a rischio se è presente un singolo componente senza patch.
Diciamo che la versione 1 della libreria A nel tuo software presenta una vulnerabilità. Questo problema si manifesta solo quando la libreria A è presente con la versione 2 della libreria B. Esiste una patch di sicurezza ma non tutti l'avrebbero installata. Ciò significa che il documento VEX per quella vulnerabilità nel tuo software deve coprire tutte le possibili combinazioni del prodotto, delle sue versioni, delle sue librerie contenute, delle loro versioni e delle possibili patch rilasciate. Si tratta di informazioni complesse che non è facile esprimere in modo semplice.
- In che modo VEX coprirebbe il software incorporato nell'hardware con tutte le possibili versioni e patch disponibili lì? Di chi sarebbe la responsabilità di applicare una patch a questo software considerando che non è possibile aprire facilmente l'hardware e applicare le patch da soli?
Questi sono solo alcuni dei problemi che qualsiasi strumento automatico per gestire VEX dovrebbe comprendere e tenere in considerazione.
Non sarebbe più semplice se potessi richiedere e ottenere informazioni per qualsiasi versione?
Il presupposto che il modo migliore per condividere queste importanti informazioni sia con un documento è probabilmente errato. Produrre abbastanza documenti VEX per coprire ogni combinazione di versione, patch e vulnerabilità è un compito epocale che, comprensibilmente, nessuno vuole intraprendere.
Scriba ha creato una piattaforma per il monitoraggio e la condivisione delle informazioni relative alla sicurezza per ciascuna build di un particolare progetto o prodotto software. Come parte di ciò, ogni build genera una SBOM accurata e un elenco di vulnerabilità scoperte nel prodotto.
Scribe consente al produttore del software di aggiungere avvisi in formato VEX a ciascuna di queste vulnerabilità per notare se non sono sfruttabili, sono sotto indagine, ecc. Una volta rilasciata una versione, tutte le informazioni di sicurezza su quella versione possono essere condivise con terze parti interessate, utenti , regolatori e così via. Includere l'elenco delle vulnerabilità e l'elenco consultivo VEX significa che il destinatario dovrebbe essere in grado di esaminare solo le vulnerabilità che rappresentano un potenziale problema in questo particolare prodotto. Questo alleggerisce notevolmente il peso sia del produttore di software che può “inserire nella whitelist” il proprio prodotto, sia del consumatore di software che capisce esattamente quale livello di rischio è coinvolto in uno specifico prodotto software.
Poiché il produttore del software è l'unico che può dire con certezza se una particolare vulnerabilità è, effettivamente, rilevante per una particolare versione del prodotto, è l'unico che può aggiungere e modificare avvisi sui propri prodotti. Il giudizio del produttore del software a questo proposito è definitivo e incontestabile. Anche la decisione su con chi condividere queste informazioni è una prerogativa del produttore del software.
Poiché la cronologia completa delle build del prodotto, delle SBOM e delle informazioni sulla sicurezza viene salvata da Scribe, gli utenti possono facilmente richiedere e ottenere queste informazioni per qualsiasi versione che potrebbero utilizzare durante l'intero ciclo di vita del software.
Conclusione
Ricorda che oggigiorno qualsiasi scansione decente di un prodotto software produrrebbe centinaia se non migliaia di possibili vulnerabilità. La maggior parte delle persone non riesce a gestire un numero del genere. La fatica dell’allerta comincia a farsi sentire e il numero delle vulnerabilità diventa proprio questo: un numero.
La possibilità di ridurre il numero dei problemi rilevati a un livello gestibile sarebbe un vantaggio per i produttori e gli utenti di software. L'obiettivo è concentrarsi solo sui problemi reali in modo che il produttore del software sia in grado di applicare patch e risolverli il prima possibile.
Strumenti automatizzati, come Scriba offrono un modo semplice per vedere solo le vulnerabilità rilevanti per ciascuno dei tuoi progetti e build, informazioni che puoi facilmente condividere, rendendo la montagna di vulnerabilità significativamente più piccola e molto più gestibile.
Un avvertimento importante però è che questo futuro, in cui possiamo facilmente vedere e rispondere solo alle vulnerabilità rilevanti, non sarebbe possibile senza la partecipazione attiva della comunità open source. La maggior parte del codice oggigiorno è costituito da quantità significative di software open source, quindi abbiamo bisogno che i manutentori e gli sviluppatori di tali librerie prendano parte alla scoperta e alla correzione delle vulnerabilità sfruttabili che affliggono il loro codice.
Il problema delle vulnerabilità rilevanti e sfruttabili non scompare, quindi spetta a tutti noi trovare il modo più efficiente ed economicamente vantaggioso per ottenere la risposta alla domanda: "la mia versione di questo software è sfruttabile a questo scopo?" vulnerabilità'.
Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.
Post Correlati
