Molti nel nostro settore stanno soppesando i vantaggi che le distinte base software (SBOM) potrebbero apportare alla qualità e alla sicurezza del software. Penso che le SBOM siano necessarie per comprendere e valutare il rischio nel software perché dovrebbero fornire visibilità nel processo di costruzione del software per un determinato sistema software. A un certo livello esistono già SBOM per determinati prodotti e sistemi software; tuttavia, la loro applicazione per la valutazione della qualità e della sicurezza come stabilito in Ordine esecutivo 14028, miglioramento della sicurezza informatica della nazione e la recente guida federale dell'Office of Management and Budget degli Stati Uniti, del National Institute of Standards and Technology e della Cybersecurity Infrastructure and Security Agency è abbastanza nuova e non provata su larga scala.

Il Royce Bill che non è mai passato

Intorno al 2013, legislazione SBOM HR5793 – Legge sulla gestione e la trasparenza della catena di approvvigionamento informatica (noto come Royce Bill) è stato introdotto ma non ha mai ottenuto lo slancio necessario per passare come mandato, disegno di legge o requisito. L'industria non aveva quindi l'appetito per la trasparenza per gestire il rischio della catena di fornitura del software.

Le questioni che questa legislazione avrebbe affrontato sono delineate nel Record del Congresso - Estensioni delle osservazioni. Questi problemi sono stati esacerbati a causa dell'enorme quantità di complessità e dimensioni crescenti nello sviluppo del software moderno e del tasso crescente di attacchi contro il software open source. Con l'aumento del tasso di utilizzo del software open source nello sviluppo software moderno, i consumatori devono essere consapevoli del debito tecnico nei progetti software open source che si è accumulato nel tempo per gestire meglio il rischio software. L'idea di una maggiore complessità del software, di sistemi software più grandi e di un debito tecnico crescente non è di buon auspicio per il desiderio del governo federale di integrità e affidabilità del software attraverso la catena di fornitura del software.

Il fatto che il Royce Bill non sia stato approvato può essere visto come un'opportunità persa per affrontare le crescenti minacce e rischi nella sicurezza del software in quel momento. Quasi un decennio dopo, l'industria sta ancora lottando per capire come implementare le SBOM e trovare il giusto equilibrio per renderle utili e non un bersaglio da sfruttare per gli avversari. Ciò solleva grande preoccupazione nell'industria sul fatto che Le SBOM sono pronte per la prima serata dato lo scetticismo riguardo agli attuali requisiti delineati nelle linee guida federali.

SBOM deve informare sui rischi sconosciuti

Una delle sfide per gli SBOM è l'avanzamento e la comprensione di come viene determinato il software rischioso. Uso il termine "rischioso" perché tutti i software presentano vulnerabilità e la SBOM deve essere in grado di differenziare o fornire un contesto al livello di rischio associato a un componente software, sia isolatamente che una volta che è stato implementato e integrato in un sistema software . Dire semplicemente che non è possibile utilizzare questo componente software perché ha CVE (vulnerabilità ed esposizioni comuni) ad esso associate diventa discutibile perché tutto il software può avere vulnerabilità. Gli SBOM devono essere in grado di qualificare sinteticamente quali CVE sono i più pericolosi e sfruttabili dato il contesto in cui il software verrà implementato e utilizzato: la funzione del componente (registrazione, crittografia, controllo degli accessi, autorizzazione), l'ambiente e se può essere rafforzato ridurre una determinata superficie di attacco. Il modo in cui i componenti software sono integrati in un sistema è importante perché i componenti software possono essere implementati male o in modo errato, esponendo le vulnerabilità nei sistemi software.

L'utilizzo di CVE per stabilire una base di sicurezza per il consumo di software open source ha senso; tuttavia, il conteggio di una serie di CVE per determinare quale software è meno rischioso o più rischioso si concentra solo sui "noti noti" (come mostrato nella figura seguente) e fa ben poco per aiutare le organizzazioni a capire quali punti deboli sono in agguato che potrebbero esporre vulnerabilità e impatto l'igiene generale di quel componente software (per un periodo di tempo). Inoltre, lo stato attuale delle pratiche relative alle SBOM non incoraggia i fornitori di software a comprendere il difetto tassi di propensione o propensione all'attacco associati al software. Questo è importante perché alcuni componenti software sono altamente mirati e richiedono patch significative a causa del debito tecnico intrinseco, della bassa qualità del codice e dei problemi di sicurezza che espongono le vulnerabilità. Più patch significa che sviluppatori e team di ingegneri dedicano meno tempo alla creazione e alla distribuzione di nuove caratteristiche e funzionalità ai clienti.

La propensione al difetto si riferisce alla probabilità che un componente software sia difettoso dopo il rilascio di un prodotto software. Ci sono vari fattori socio-tecnici che contribuiscono alla propensione ai difetti come bassa qualità del codice e difetti di progettazione. La propensione agli attacchi si riferisce alla velocità con cui i componenti software possono essere sfruttati con successo o alla probabilità che i componenti software contengano punti deboli sfruttabili - bug, difetti o falle - o vulnerabilità.

Le soluzioni SBOM devono offrire alle organizzazioni la visibilità del rischio potenziale per un determinato componente software, come mostrato nella figura sopra, aiutando le organizzazioni a prendere decisioni informate su quali componenti software utilizzare e quali componenti software evitare. Ad esempio, consigli nel Scheda informativa sulla sicurezza informatica della National Security Agency (NSA). incoraggia gli sviluppatori a evitare di utilizzare software sviluppato in C e C++ perché quei linguaggi di programmazione non erano destinati a imporre buoni controlli di gestione della memoria. Sarà interessante vedere in che modo questo consiglio influenzerà la catena di fornitura del software, principalmente per i sistemi critici per la sicurezza incorporati, e se i fornitori si rivolgeranno a linguaggi di programmazione sicuri per la memoria, come Rust and Go.

Approfondisci per guidare SBOM

Le SBOM non scompariranno, quindi è imperativo che tutti noi collaboriamo e collaboriamo per migliorare la sicurezza del software. Ciò potrebbe richiedere lo sviluppo di strumenti e standard in grado di arricchire le SBOM e fornire analisi e approfondimenti approfonditi sulle caratteristiche del software che aiutano a informare sui rischi del software. Ciò aiuterà le organizzazioni a valutare e attestare in modo efficace l'integrità del software, nonché altre proprietà di software assurance. In definitiva, è importante che i fornitori di software comprendano non solo il rischio associato a un determinato componente software, ma anche la potenziale manutenzione associata all'utilizzo di tale componente software per un periodo di tempo, date le sfide del settore per correggere le vulnerabilità del software in modo tempestivo . L'uso dei tassi di propensione ai difetti e agli attacchi potrebbe fornire informazioni utilizzabili che aiutano a ridurre il consumo di software rischioso con scarsa igiene, e guidare i fornitori di software nella creazione di sistemi software più resistenti agli attacchi informatici. 

In teoria, i componenti software con elevati tassi di difettosità e propensione agli attacchi dovrebbero essere evitati per aiutare a stimolare e incoraggiare l'uso di alternative con una migliore igiene. Secondo me, SBOM non migliorano direttamente la qualità e la sicurezza del codice, ma possono rendere i fornitori di software più consapevoli dei rischi nel loro processo di costruzione del software. Il miglioramento della qualità e della sicurezza del codice per il software open source richiede un cambiamento culturale avere molti occhi non rende tutti gli insetti superficiali.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
• Fonte: https://www.darkreading.com/vulnerabilities-threats/don-t-be-blindsided-by-software-bills-of-materials