Le principali conclusioni di questo articolo:
Una distinta base del software (SBOM) elenca tutti i componenti del software, garantendo chiarezza e controllo sulle catene di fornitura.
Gli SBOM consentono di rispondere rapidamente alle vulnerabilità, come dimostrato da Log4j e SolarWinds, rafforzando le difese della supply chain.
Gli obblighi normativi come PCI DSS e i requisiti governativi collegano direttamente la sicurezza all'adozione di SBOM.
L'automazione della generazione SBOM elimina gli errori e garantisce un monitoraggio aggiornato delle vulnerabilità.
La scansione SBOM senza agente di Wiz offre informazioni in tempo reale, aiutando i team a rimanere al passo con gli ambienti software in continua evoluzione.
Cos'è uno SBOM?
Una distinta base del software (SBOM) è un inventario completo che descrive in dettaglio ogni componente software che costituisce un'applicazione. Include librerie open source e commerciali di terze parti, chiamate API, versioni e licenze.
Le applicazioni utilizzate nell'ecosistema della supply chain sono un amalgama di elementi provenienti da diverse fonti. Queste fonti possono contenere vulnerabilità che i criminali informatici potrebbero sfruttare durante gli attacchi alla supply chain. Gli SBOM semplificano la gestione delle vulnerabilità fornendo informazioni su questi elementi.
Se integrati nel ciclo di vita della distribuzione del software (SDLC), gli SBOM migliorano la visibilità sullo stato delle patch e delle licenze dei software di terze parti e forniscono altre informazioni relative alla sicurezza che possono rafforzare l'integrità del codice.
Il ruolo di SBOM nella sicurezza della supply chain del software
Con l'aumento degli attacchi alla supply chain, gli SBOM sono diventati strumenti essenziali per tracciare e proteggere i componenti software. Gartner stima che entro il 2025 il 60% delle organizzazioni richiederà gli SBOM come parte delle proprie pratiche di sicurezza informatica, un aumento significativo rispetto al 20% del 2022. Anche i mandati governativi, come l' Ordine esecutivo della Casa Bianca sul miglioramento della sicurezza informatica della nazione , ora richiedono gli SBOM per le organizzazioni che lavorano con agenzie governative.
Gli incidenti Log4j e SolarWinds evidenziano l'importanza degli SBOM:
Vulnerabilità Log4j (CVE-2021-44228): questa libreria Java ampiamente utilizzata ha creato un incubo di sicurezza per le organizzazioni di tutto il mondo. Senza SBOM, molte aziende si sono ritrovate a dover fare i conti, mettendo insieme i componenti a rischio. Quelle con SBOM, invece? Hanno individuato rapidamente i componenti interessati, schivando enormi ricadute.
Attacco SolarWinds : nel 2020, gli aggressori hanno compromesso il software SolarWinds Orion, colpendo circa 18.000 clienti, tra cui aziende di alto livello e agenzie governative. Uno SBOM avrebbe potuto fare breccia nel caos, aiutando le vittime a rintracciare rapidamente il malware e a rispondere in modo efficace.
Procedure consigliate per la sicurezza CI/CD [Promemoria]
Scopri di più sulla sicurezza dell'infrastruttura, sulla sicurezza del codice, sull'accesso e sul monitoraggio con elementi pratici, frammenti di codice e screenshot.
Ottieni il foglio riepilogativo
Perché gli SBOM sono importanti
Gli SBOM forniscono un elenco dettagliato di tutti i componenti di un'applicazione software, aiutando le organizzazioni a identificare e gestire i rischi per la sicurezza. Migliorano inoltre la trasparenza, semplificano il monitoraggio e l'aggiornamento delle dipendenze software e altro ancora:
1. Trasparenza e visibilità
Pensate agli SBOM come al blueprint del vostro software. Offrono agli sviluppatori una visione chiara di tutti i componenti software di terze parti, come le librerie open source, utilizzati nelle loro applicazioni. Questa trasparenza aiuta i team a soppesare i rischi prima di aggiungere una libreria e a rimanere al passo con le vulnerabilità dopo la distribuzione.
2. Conformità normativa
Con i governi e gli standard di settore che reprimono la sicurezza del software, gli SBOM sono diventati un elemento essenziale per la conformità. Da PCI DSS a HIPAA, molte normative ora richiedono una chiara registrazione dei componenti software. Uno SBOM non solo aiuta a soddisfare questi requisiti, ma tiene anche la tua organizzazione fuori dai guai, che si tratti di multe o danni alla reputazione dovuti a incidenti di licenza.
3. Risposta agli incidenti e analisi forense
Quando qualcosa va storto, uno SBOM può essere una salvezza. Individua esattamente quale componente è vulnerabile, aiutando i team a concentrarsi sull'area problematica, a stabilire le priorità della risposta e a valutare l'impatto più ampio.
Cosa dovrebbe includere uno SBOM?
Uno SBOM dovrebbe includere dettagli su tutti i componenti software open source e proprietari utilizzati in un prodotto, inclusi i loro nomi, versioni e licenze. Dovrebbe anche specificare le relazioni tra i componenti e le loro dipendenze.
In uno SBOM devono essere presenti i seguenti elementi chiave:
1. Identificatori dei componenti: includono metadati quali nomi di fornitori e componenti, origini dei componenti, descrizione e responsabili, ID dell'artefatto, timestamp, numero di versione e riferimenti specifici, quali ID di commit Git o hash SHA-1 per ogni componente.
2. Dipendenze: la relazione tra ciascun componente e le sue dipendenze deve essere chiaramente documentata.
3. Informazioni sulla versione: includono il numero di versione del software, il nome del file e il sistema operativo per consentire una facile installazione e prevenire problemi di compatibilità. Le informazioni sulla versione consentono di tenere traccia degli aggiornamenti o delle patch necessarie per ciascun componente.
4. Dati sulle vulnerabilità: è essenziale includere informazioni sulle vulnerabilità note associate a ciascun componente. Questi dati possono essere ottenuti da cataloghi di vulnerabilità come il National Vulnerability Database (NVD) o CVE (Common Vulnerabilities and Exposures).
5. Informazioni sulla licenza: ogni componente ha termini di licenza (ad esempio, licenze MIT, Apache e BSD). Lo SBOM deve contenere questi termini per garantire la conformità con gli obblighi di licenza.
7. Riferimenti esterni: includono URL o documentazione relativa a ciascun componente. Forniscono contesto aggiuntivo sulle funzioni dei componenti.
Consiglio da professionista L'SBOM senza agente di Wiz consente di ottenere una visibilità completa dei componenti delle applicazioni, inclusi pacchetti, librerie open source e dipendenze nidificate, senza punti ciechi e senza dover distribuire un agente.
Saperne di più
Formati SBOM comuni
Gli SBOM possono essere generati manualmente o automaticamente.
Il metodo manuale prevede l'elencazione di tutti i componenti software e delle rispettive versioni, licenze e dipendenze in fogli di calcolo. È adatto solo a distribuzioni su piccola scala ed è soggetto a errori umani.
Il metodo automatico prevede l'integrazione degli strumenti SBOM nella pipeline di integrazione continua/distribuzione continua (CI/CD).
Dopo la generazione, gli SBOM sono strutturati in due formati principali: CycloneDX e Software Package Data Exchange (SPDX). Di seguito una breve descrizione di ciascuno.
| Format | Description |
|---|---|
| SPDX | SPDX supporta la rappresentazione delle informazioni SBOM, come l'identificazione dei componenti e le informazioni sulle licenze, insieme alla relazione tra i componenti e l'applicazione. SPDX consente la raccolta e la condivisione delle informazioni in vari formati di file, inclusi formati leggibili dall'uomo e analizzabili dalla macchina come JSON, XML e YAML. Migliora la trasparenza e facilita la conformità delle licenze. |
| CycloneDX | CycloneDX supporta l'elencazione di componenti/servizi interni ed esterni che costituiscono le applicazioni insieme alle loro interrelazioni, allo stato delle patch e alle varianti. Struttura i dati come file XML o JSON e consente di aggiungere dettagli come punteggi e descrizioni del Common Vulnerability Scoring System (CVSS) allo SBOM. CycloneDX è altamente estensibile, consentendo agli sviluppatori di aggiungere nuove funzionalità in base alle necessità. |
Per comprendere meglio i formati SBOM, prendi in considerazione questo esempio dell'inventario CycloneDX in formato JSON:
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79",
"version": 1,
"components": [
{
"type": "library",
"name": "nacl-library",
"version": "1.0.0"
}
]
}Oltre ai due formati trattati sopra, le organizzazioni possono anche utilizzare tag Software Identification (SWID), che di solito vengono installati durante la distribuzione. I tag SWID forniscono informazioni SBOM come date di rilascio e licenze dei componenti software. Gli enti normativi e il governo degli Stati Uniti considerano i tag SWID, CycloneDX e SPDX come formati SBOM accettabili .
Implementazione SBOM: una guida passo passo
Creare uno SBOM potrebbe sembrare scoraggiante, ma suddividerlo in passaggi gestibili può semplificare il processo. Ecco come iniziare:
| Step | Process |
|---|---|
| 1. Scegli gli strumenti SBOM | Inizia con strumenti adatti al tuo flusso di lavoro. Che si tratti di opzioni open source come CycloneDX e SPDX o strumenti commerciali, assicurati che siano all'altezza del compito. Cerca quelli che si sincronizzano senza problemi con le tue pipeline CI/CD e che possono gestire la scala delle tue operazioni con l'automazione. |
| 2. Automatizzare la generazione SBOM | La generazione manuale di SBOM è una ricetta per errori e frustrazione. Automatizzala invece. Imposta script o plugin CI/CD che aggiornino il tuo SBOM ogni volta che c'è una nuova build. Mantiene le cose aggiornate e fa risparmiare tempo e fatica al tuo team. |
| 3. Monitorare e aggiornare i componenti software | Il software non è statico, si evolve. Monitora i tuoi componenti di terze parti per nuove versioni, patch o vulnerabilità. Rendi la revisione e l'aggiornamento del tuo SBOM un'abitudine regolare. Questo approccio proattivo ti assicura di essere pronto ad agire rapidamente quando emergono rischi per la sicurezza. |
| 4. Rivedere e monitorare la conformità | Le normative possono essere un bersaglio mobile, quindi integra i controlli di conformità nella tua routine. Ogni componente soddisfa gli standard di licenza e sicurezza? Esegui audit per un doppio controllo. Uno SBOM trasparente e aggiornato è la tua rete di sicurezza per evitare sorprese durante un audit o una violazione. |
Finding the needle in the haystack: effortless SBOM search in your cloud with Wiz
Leggi di più
L'approccio di Wiz alla sicurezza SBOM
Wiz Code migliora la sicurezza SBOM (Software Bill of Materials) fornendo una visibilità completa sui componenti e sulle dipendenze all'interno del tuo software. Con la scansione in tempo reale e i controlli di sicurezza automatizzati, Wiz Code garantisce che le vulnerabilità all'interno di librerie di terze parti e componenti open source siano identificate e mitigate in anticipo.
Ecco alcuni vantaggi dell'implementazione SBOM senza agente:
Flessibilità e semplicità: gli agenti dedicati sono servizi aggiuntivi che consumano risorse e necessitano di manutenzione continua, aggiungendo un overhead di manutenzione alle stelle. L'implementazione SBOM senza agente riduce anche i costi ed elimina i problemi di compatibilità agente-OS.
Visibilità immediata e completa: gli agenti devono essere installati su ogni sottosistema nello stack software. Uno SBOM senza agenti ti offre una visione completa dei componenti delle tue applicazioni, dalle librerie open source in uso al pacchetto e alle dipendenze nidificate, in pochi minuti, senza punti ciechi.
Ricerca SBOM: cerca e individua rapidamente specifici pacchetti OS e open source in tutti gli ambienti cloud. Questa capacità è particolarmente tempestiva date le recenti vulnerabilità critiche trovate in librerie ampiamente utilizzate come xz-utils .
Sempre aggiornato: gli agenti richiedono un'installazione manuale che può essere soggetta a errori, mentre un approccio senza agenti consente di generare SBOM aggiornati senza intervento manuale.
Generazione SBOM senza agente
Ottieni una visibilità completa dei componenti delle tue applicazioni, inclusi pacchetti, librerie open source e dipendenze nidificate, senza punti ciechi.
