Un inventario nidificato per la sicurezza del software, la gestione del rischio della catena di fornitura

Inventario nidificato per sicurezza software e gestione rischio catena di fornitura

Il Software Bill of Materials (SBOM) è composto da tutti i componenti e librerie utilizzati per creare un'applicazione software. Include una descrizione di tutte le licenze, versioni, autori e stato delle patch. ¶ Credito: ReversingLabs

Con violazioni dei dati di alto profilo come Kaseya e Apache Log4j che continuano a causare ripercussioni, la sicurezza della catena di approvvigionamento del software è sotto esame come mai prima d’ora. Questo ha spinto l’Ordine Esecutivo 2021 dell’Amministrazione Biden per il miglioramento della sicurezza informatica della nazione, che richiede agli sviluppatori di fornire un Software Bill of Materials (SBOM).

Pensa a un SBOM come agli ingredienti in una ricetta: è composto da tutti i componenti e librerie utilizzati per creare un’applicazione software. Include una descrizione di tutte le licenze, versioni, autori e stato delle patch.

Molti di questi componenti sono open source e un SBOM ha lo scopo di fornire visibilità sui rischi e le vulnerabilità. Dopotutto, se non sai quale codice stai proteggendo, come puoi mantenerlo?

Il ruolo degli SBOM

Quando le organizzazioni hanno questa visibilità, sono in grado di individuare meglio vulnerabilità note o emergenti e rischi, abilitare la sicurezza tramite il design e prendere decisioni informate sulla logistica della catena di approvvigionamento del software e sulle questioni di acquisizione. “E questo è sempre più importante perché gli attori minacciosi sofisticati considerano gli attacchi alla catena di approvvigionamento come uno strumento principale per attività cibernetica malintenzionata”, secondo Booz Allen Hamilton.

Entro il 2025, il 60% delle organizzazioni che costruiscono o acquistano software per infrastrutture critiche richiederà e standardizzerà gli SBOM nella loro pratica di ingegneria del software, rispetto al meno del 20% nel 2022, secondo la società di ricerca di mercato Gartner.

“Diversi fattori stanno portando alla necessità di SBOM”, afferma Manjunath Bhat, vicepresidente delle ricerche presso Gartner. Tra questi fattori vi sono l’aumento dell’uso di dipendenze di terze parti e software open source, l’aumento degli attacchi alla catena di approvvigionamento del software e le normative sulla conformità per garantire l’uso sicuro di OSS, afferma Bhat.

“La visibilità dettagliata e la trasparenza sull’intera catena di approvvigionamento del software sono ciò che rende gli SBOM così preziosi”, afferma.

Elementi degli SBOM

La National Telecommunications and Information Agency (NTIA) e il Dipartimento del Commercio degli Stati Uniti sono stati incaricati di pubblicare gli elementi minimi per un SBOM, insieme a una descrizione dei casi d’uso per una maggiore trasparenza nella catena di approvvigionamento.

Hanno stabilito che dovrebbero esserci campi dati per un fornitore, il nome e la versione del componente, nonché la relazione di dipendenza, tra le altre aree, hanno dichiarato la NTIA e il Dipartimento del Commercio.

Hanno anche raccomandato la presenza di funzionalità di generazione automatica dei dati e di lettura da parte delle macchine per consentire la scalabilità di un SBOM nell’ecosistema del software. Ci sono anche tre formati per la generazione di SBOM generalmente accettati: SPDX, CycloneDX e SWID tags.

Gli SBOM sono progettati per far parte dei flussi di lavoro automatizzati, osserva Bhat. “Pertanto, la standardizzazione dei formati dei dati e l’interoperabilità tra di loro saranno fondamentali”.

I campi dati all’interno di un SBOM “includono elementi che aiutano a identificare in modo univoco e inequivocabile i componenti software e le loro relazioni tra loro”, afferma. “Pertanto, gli elementi di base includono il nome del componente, il nome del fornitore, la versione del componente, identificatori univoci (molto probabilmente una firma digitale o un hash crittografico) e le relazioni di dipendenza”.

Le piattaforme SBOM che sono automatiche e dinamiche sono ideali perché possono essere aggiornate continuamente per garantire che gli sviluppatori di software abbiano una visione accurata dei componenti e delle dipendenze utilizzate nelle loro applicazioni.

Come possono essere utilizzati gli SBOM

Ci sono alcuni buoni casi d’uso per come gli SBOM possono essere utilizzati. Questi includono:

  • aiutare nelle decisioni di approvvigionamento e adozione del software per ridurre i problemi di conformità e prevenire acquisti duplicati;
  • migliorare l’intelligence sulle minacce e la gestione delle vulnerabilità mediante il monitoraggio dei componenti compromessi e la pianificazione delle correzioni;
  • accelerare la risposta agli incidenti e guidare l’implementazione delle patch e
  • fornire la possibilità di mappare le dipendenze nell’ecosistema di un’organizzazione attraverso l’ecosistema esterno del software.

Bhat afferma che non ci sono reali svantaggi degli SBOM, ma osserva che “Sono utili solo nella misura in cui sono completi e accurati. Gli SBOM parzialmente completi o obsoleti sono tanto utili quanto non averne affatto.” Inoltre, “È importante per noi come industria convergere su un paio di formati SBOM facili da produrre e da utilizzare”.

Gli SBOM sono progettati per tracciare e condividere i dettagli dei componenti software e le loro relazioni nella catena di approvvigionamento tra le organizzazioni, e ciò permette una maggiore trasparenza, auditabilità e tracciabilità, afferma Bhat. Questo è utile per accelerare la risoluzione di problemi di sicurezza e conformità.

“Gli SBOM aiutano anche le organizzazioni a determinare se sono suscettibili a vulnerabilità di sicurezza note nei componenti software”, afferma. “Gli SBOM generano e verificano informazioni sulla provenienza del codice e le relazioni tra i componenti, il che aiuta i team di ingegneria del software a rilevare attacchi dannosi durante lo sviluppo.”

Utilizzo degli SBOM

Microsoft sta generando e utilizzando gli SBOM per dare priorità alla sicurezza del software e preparare il software per i clienti, afferma Adrian Diglio, responsabile principale del programma di gestione della catena di approvvigionamento del software sicuro (S3C) presso Microsoft.

Il gigante del software ha creato uno strumento SBOM che gli sviluppatori eseguono internamente durante la creazione, che produce un SBOM in formato SPDX che può essere condiviso con i clienti, afferma Diglio. Lo scorso anno, Microsoft ha reso open source lo strumento SBOM per consentire alla comunità di utilizzarlo e svilupparlo ulteriormente.

Ora, “Microsoft sta preparando organizzativamente l’intera azienda per iniziare a consumare e gestire gli SBOM di terze parti”, afferma. “Come parte di questo sforzo, abbiamo una versione preliminare disponibile per coloro che fanno parte del programma Windows Insider del Windows Driver Kit (WDK) e del Windows Assessment and Deployment Kit (ADK) che contiene il nostro strumento SBOM.”

Alcuni dei suoi prodotti SBOM sono anche pubblicamente disponibili, aggiunge Diglio.

“Attraverso il nostro lavoro con lo strumento SBOM e il Secure Supply Chain Consumption Framework (S2C2F), Microsoft sta continuamente ribadendo l’importanza del software open source… per affrontare la sua sicurezza”, afferma.

Esther Shein è una scrittrice freelance di tecnologia e business con sede nell’area di Boston.