Che cos'è una SBOM?
Una distinta base del software (SBOM) elenca tutti i componenti del software, garantendo chiarezza e controllo sulle catene di approvvigionamento.
Le SBOM consentono risposte rapide alle vulnerabilità, come si è visto con Log4j e SolarWinds, rafforzando le difese della supply chain.
I mandati normativi come PCI DSS e i requisiti governativi legano la sicurezza direttamente all'adozione della SBOM.
L'automazione della generazione di 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 i cambiamenti degli ambienti software.
Che cos'è una SBOM?
Una distinta base software (SBOM) è un inventario completo che descrive in dettaglio ogni componente software che compone un'applicazione. Comprende open source e librerie 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 catena di approvvigionamento. SBOM semplificano Gestione delle vulnerabilità fornendo informazioni su tali elementi.
Gartner prevede che entro il 2025
Modellino di ricerca'nel ruolo della supply chain del software
Con l'aumento degli attacchi alla catena di approvvigionamento, le SBOM sono diventate strumenti essenziali per il monitoraggio e la protezione dei componenti software. Gartner stima che entro il 2025 Il 60% delle organizzazioni richiederà le SBOM nell'ambito delle loro pratiche di sicurezza informatica, un aumento significativo rispetto al 20% del 2022. mandati governativi, come quello della Casa Bianca Ordine esecutivo per il miglioramento della nazione's Sicurezza informatica, ora richiedono anche le SBOM per le organizzazioni che lavorano con le agenzie governative.
Gli incidenti di Log4j e SolarWinds evidenziano l'importanza delle SBOM:
Vulnerabilità di Log4j (CVE-2021-44228): Questa libreria Java ampiamente utilizzata ha creato un incubo per la sicurezza per le organizzazioni di tutto il mondo. Senza le SBOM, molte aziende si sono trovate a dover mettere insieme i componenti a rischio. Quelli con SBOM, però? Hanno individuato rapidamente i componenti colpiti, schivando le massicce 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. Una SBOM avrebbe potuto eliminare il caos, aiutando le vittime a rintracciare rapidamente il malware e a rispondere in modo efficace.
CI/CD Security Best Practices [Cheat Sheet]
Learn about infrastructure security, code security, access, and monitoring with actionable items, code snippets, and screenshots.
Get the Cheat Sheet
Perché le SBOM sono importanti
Le 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 anche la trasparenza, semplificano il monitoraggio e l'aggiornamento delle dipendenze software e altro ancora:
1. Trasparenza e visibilità
Pensa alle SBOM come al progetto del tuo 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 valutare i rischi prima di aggiungere una libreria e a tenere sotto controllo le vulnerabilità dopo l'implementazione.
2. Conformità normativa
Con i governi e gli standard di settore che reprimono la sicurezza del software, le SBOM sono diventate un elemento essenziale per la conformità. Da PCI DSS a HIPAA, molte normative richiedono ora una registrazione chiara dei componenti software. Una SBOM non solo aiuta a soddisfare questi requisiti, ma mantiene 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, una SBOM può essere un vero toccasana. Individua esattamente quale componente è vulnerabile, aiutando i team a concentrarsi sull'area problematica, dare priorità alla loro rispostae valutarne l'impatto più ampio.
Cosa dovrebbe includere una SBOM?
Una SBOM deve includere dettagli su tutti i componenti software open source e proprietari utilizzati in un prodotto, inclusi i nomi, le versioni e le licenze. Dovrebbe anche specificare le relazioni tra i componenti e le loro dipendenze.
Una SBOM dovrebbe includere dettagli su tutti i componenti software open source e proprietari utilizzati in un prodotto, inclusi i nomi, le versioni e le licenze. Dovrebbe inoltre specificare le relazioni tra i componenti e le relative dipendenze.
1. Identificatori dei componenti: Sono inclusi metadati come nomi di fornitori e componenti, origini dei componenti, descrizione e manutentori, ID artefatto, timestamp, numero di versione e riferimenti specifici, come ID commit Git o hash SHA-1 per ogni componente.
2. Dipendenze: La relazione tra ogni componente e le sue dipendenze deve essere chiaramente documentata.
3. Informazioni sulla versione: Ciò include il numero di versione del software, il nome del file e il sistema operativo per consentire una facile installazione ed evitare problemi di compatibilità. Le informazioni sulla versione consentono di tenere traccia degli aggiornamenti o delle patch necessari per ciascun componente.
4. Dati sulla 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 sulle licenze: Ogni componente ha termini di licenza (ad esempio, licenze MIT, Apache e BSD). La SBOM deve contenere questi termini per garantire la conformità agli obblighi di licenza.
7. Riferimenti esterni: Questi includono URL o documentazione relativa a ciascun componente. Forniscono un contesto aggiuntivo sulle funzioni dei componenti.
Wiz’s agentless SBOM allows you to gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots and deploying an agent.
Formati SBOM comuni
Le SBOM possono essere generate manualmente o automaticamente.
Le Metodo manuale comporta l'elenco 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.
Le Metodo automatico comporta 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 è riportata una breve descrizione di ciascuno.
| Format | Description |
|---|---|
| SPDX | SPDX supports representation of SBOM information, such as component identification and licensing information, alongside the relationship between the components and the application. SPDX enables information gathering and sharing in various file formats, including human-readable and machine-parsable formats such as JSON, XML, and YAML. It enhances transparency, and facilitates license compliance. |
| CycloneDX | CycloneDX supports listing internal and external components/services that make up applications alongside their interrelationships, patch status, and variants. It structures the data as an XML or JSON file, and enables you to add details such as Common Vulnerability Scoring System (CVSS) scores and descriptions to the SBOM. CycloneDX is highly extensible, allowing developers to add new capabilities as required. |
Per comprendere meglio i formati SBOM, si consideri questo esempio dell'inventario CycloneDX in formato JSON:
{
"bomFormat": "CicloneDX",
"specVersion": "1.4",
"numero seriale": "urna: uuid:3e673487-395b-41h8-a30f-a58468a69b79",
"Versione": 1,
"Componenti": [
{
"digitare": "biblioteca",
"nome": "Libreria NACL",
"Versione": "1.0.0"
}
]
}Oltre ai due formati descritti in precedenza, le organizzazioni possono anche utilizzare i tag SWID (Software Identification), che in genere vengono installati durante la distribuzione. I tag SWID forniscono informazioni SBOM come le date di rilascio dei componenti software e le licenze. Gli organismi di regolamentazione e il governo degli Stati Uniti considerano accettabili i tag SWID, CycloneDX e SPDX Formati SBOM.
Implementazione della SBOM: una guida passo passo
La creazione di una SBOM potrebbe sembrare scoraggiante, ma suddividerla in passaggi gestibili può semplificare il processo. Ecco come iniziare:
| Step | Process |
|---|---|
| 1. Choose SBOM tools | Start with tools that fit your workflow. Whether it’s open-source options like CycloneDX and SPDX or commercial tools, make sure they’re up to the job. Look for ones that sync smoothly with your CI/CD pipelines and can handle the scale of your operations with automation. |
| 2. Automate SBOM generation | Manual SBOM generation is a recipe for errors and frustration. Automate it instead. Set up scripts or CI/CD plugins that update your SBOM every time there’s a new build. It keeps things current and saves your team time and effort. |
| 3. Track and update software components | Software isn’t static—it evolves. Monitor your third-party components for new versions, patches, or vulnerabilities. Make reviewing and updating your SBOM a regular habit. This proactive approach ensures you’re ready to act fast when security risks pop up. |
| 4. Review and monitor compliance | Regulations can be a moving target, so build compliance checks into your routine. Does every component meet licensing and security standards? Conduct audits to double-check. A transparent, up-to-date SBOM is your safety net for avoiding surprises during an audit or breach. |
Finding the needle in the haystack: effortless SBOM search in your cloud with Wiz
Leggi di più
Wiz'L'approccio alla sicurezza delle SBOM
Wiz Code migliora la sicurezza SBOM (Software Bill of Materials) fornendo una visibilità completa dei componenti e delle dipendenze all'interno del software. Con la scansione in tempo reale e i controlli di sicurezza automatizzati, Wiz Code garantisce che le vulnerabilità all'interno delle librerie di terze parti e dei componenti open source vengano identificate e mitigate tempestivamente.
Alcuni vantaggi della distribuzione SBOM senza agente includono:
Flessibilità e semplicità: Gli agenti dedicati sono servizi aggiuntivi che consumano risorse e necessitano di manutenzione continua, aumentando il sovraccarico di manutenzione. SBOM senza agente L'implementazione riduce inoltre i costi ed elimina i problemi di compatibilità tra agente e sistema operativo.
Visibilità istantanea e completa: Gli agenti devono essere installati in ogni sottosistema dello stack software. Una SBOM senza agente ti offre una visione completa delle tue applicazioni' Componenti, dalle librerie open source in uso al pacchetto e alle dipendenze nidificate, in pochi minuti, senza punti ciechi.
Ricerca SBOM: Cerca e individua rapidamente sistemi operativi specifici e pacchetti open source in ambienti cloud. Questa capacità è particolarmente opportuna date le recenti vulnerabilità critiche riscontrate 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 aggiornate senza intervento manuale.
Agentless SBOM Generation
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.
