״I fornitori di software devono essere ritenuti responsabili quando non riescono a rispettare il dovere di diligenza nei confronti dei consumatori, delle imprese o dei fornitori di infrastrutture critiche (la Casa Bianca).
Oggi, ci si aspetta che qualsiasi fornitore di software si assuma una maggiore responsabilità nel garantire l’integrità e la sicurezza del software attraverso accordi contrattuali, rilasci e aggiornamenti del software, notifiche e mitigazione delle vulnerabilità. Recentemente, l'ESF (Enduring Security Framework), un gruppo di lavoro intersettoriale, ha pubblicato linee guida che includono best practice e standard consigliati per assistere i clienti nell'implementazione di misure di sicurezza all'interno della catena di fornitura del software. In questo articolo approfondirò ulteriormente la raccomandazione pratica di utilizzare il punteggio di rischio basato sulla SBOM come meccanismo efficace per il triage e la definizione delle priorità.
Persistono metodi comuni per compromettere le catene di fornitura del software, tra cui lo sfruttamento dei difetti di progettazione del software, l'incorporazione di componenti vulnerabili di terze parti in un prodotto software, l'infiltrazione di codice dannoso nella rete del fornitore prima della consegna finale del prodotto software e l'iniezione di software dannoso nel software distribuito nell'ambiente del cliente.
Una distinta dei materiali del software (SBO) è emerso come un elemento cruciale nella sicurezza del software e nella gestione dei rischi della catena di fornitura del software. Una SBOM funge da inventario nidificato e fornisce un elenco di ingredienti che costituiscono i componenti software.
L’operatività delle SBOM su larga scala richiede l’automazione degli strumenti e la standardizzazione nelle implementazioni dei sistemi, nello sviluppo dei prodotti e nello scambio di dati tra fornitori di software e consumatori.
Ce ne sono alcuni importanti leggibili dalla macchina Formati standard SBOM sostenuto dall’industria. CycloneDX e SPDX definiscono il modo in cui le SBOM vengono create, analizzate e condivise. VEX è una forma complementare di avviso di sicurezza che indica se uno o più prodotti sono interessati da una o più vulnerabilità note. Offre quindi il vantaggio di dimostrare che un prodotto non è affetto da una vulnerabilità specifica, anche se tale vulnerabilità esiste nella sua SBOM.
La correlazione dei contenuti SBOM tra i prodotti software distribuiti all'interno dell'azienda può fornire informazioni approfondite ai team di sicurezza delle applicazioni, risposta agli incidenti e analisi forensi, gestione dei rischi e approvvigionamento. Ci si aspetta che le organizzazioni generino e gestiscano una grande quantità di dati SBOM per prodotti interni, oltre a consumare dati esterni che devono essere gestiti in modo efficace. Pertanto, è necessario sostenere processi automazione della SBOMgestione del rischio guidata su larga scala.
Utilizzo di SBOM e punteggio di rischio
Il punteggio di rischio può servire come mezzo per generare una panoramica condensata derivata dal contenuto della SBOM, consentendo confronti rapidi con fonti di dati esterne e facilitando un rapido processo decisionale basato sulle SBOM ricevute e sulla definizione delle priorità.
- La SBOM aumenta la trasparenza, migliorando così la gestione delle risorse software, la gestione delle patch, l'identificazione delle lacune tecniche del debito e la gestione delle vulnerabilità per le organizzazioni dei clienti. Ha anche il potenziale per estrarre la provenienza dei componenti per convalidare l'integrità e la fiducia.
- L'analisi dell'allineamento dei contenuti della SBOM tra i prodotti software implementati nell'azienda fornisce informazioni preziose per i team di risposta agli incidenti, la gestione del rischio e la convalida del processo di approvvigionamento.
Trasformare la SBOM in informazioni sul rischio su larga scala: motivazioni per il punteggio del rischio
Una sfida chiave per ogni professionista AppSec e CISO è gestire la fatica degli avvisi nei tuoi prodotti e servizi. Inclusa la valutazione dei rischi esterni derivanti da componenti software di terze parti.
I principali ostacoli all’implementazione sono il supporto contrattuale o basato su licenza obsoleto che può influire sulla disponibilità di patch downstream e aggiornamenti di prodotto e la crescita esponenziale della complessità delle dipendenze all’interno dei prodotti software, sia open source che closed source.
A punteggio di rischio è una metrica utilizzata per prevedere gli aspetti del software e il rischio attuale e futuro dei suoi componenti in grado di supportare efficacemente la definizione delle priorità su larga scala.
Punteggio di rischio = probabilità x impatto
Il punteggio del rischio consente alle organizzazioni di comprendere il rischio della catena di fornitura del software in base a fattori di rischio definiti e di anticipare il potenziale rischio futuro di un determinato prodotto software nell'azienda.
Un punteggio di rischio effettivo potrebbe essere su una scala da 1 a 10 (come CVSS e Scorecard), quindi possiamo allineare ogni componente di rischio alla scala da 1 a 10 per facilità di riferimento.
Un punteggio di rischio aggregato: In molti sistemi complessi e sistemi di sistemi, possono esserci più SBOM come parte della soluzione collettiva e, quindi, una raccolta di punteggi di rischio.
Componenti del punteggio di rischio:
1.Vulnerabilità: Mappatura delle vulnerabilità note utilizzando l'enumerazione CVE e Punteggio CVSS dai feed disponibili come NVD, OSV e Github Advisories.
2. Contesto dei fornitori: VEX e contesto di consulenza da parte dei fornitori che potrebbero modificare la decisione del punteggio di vulnerabilità nel contesto di utilizzo. Il collegamento delle SBOM alle vulnerabilità abilita i flag di rischio, mentre i documenti VEX consentono al consumatore di dare priorità alle vulnerabilità.
3. EPSS 3.0: Metrica di sfruttabilità di FIRST, che prevede la probabilità (tra 0 e 1.0) di sfruttamento nei prossimi 30 giorni. Questo è efficace ulteriore livello di verosimiglianza al punteggio CVSS che può aiutare a dare priorità ai CVE più importanti da gestire per primi.
4.KEV: CISA ha inoltre creato un feed di intelligence sulle minacce disponibile al pubblico, oggi noto come Catalogo CISA KEV (vulnerabilità note sfruttabili).. Questo catalogo contiene circa il 5% di tutti i CVE identificati che sono stati confermati dalla CISA come sfruttati o attivamente sfruttati. Pertanto, questo è un buon punto di partenza per dare priorità alle vulnerabilità ad alto impatto da affrontare. Inoltre, questo fa parte della lista di controllo da convalidare prima dell'approvazione finale del rilascio della nuova versione.
5. Informazioni sulle minacce – Aggiungi altro le fonti di minaccia e vulnerabilità alimentano pacchetti dannosi noti (Esempi: feed privati di Snyk, Sonatype, Graynoise, ecc.)
6. Reputazione OSS: Il La scorecard SSF aperta valuta in modo indipendente le metriche delle misure di prestazione che interessano diverse parti della catena di fornitura del software, tra cui codice sorgente, creazione, dipendenze, test e reputazione di manutenzione dei progetti open source (valutazione da 1 a 10).
7. Prestazioni nel tempo: Le vulnerabilità critiche MTTR (Mean Time To Repair) di una versione di prodotto/pacchetto potrebbero fornire una metrica rilevante delle prestazioni del rischio per la sicurezza.
8. urto e contesto. Sotto questo aspetto, la definizione delle priorità in base al contesto aziendale del prodotto software aiuterebbe a stabilire le priorità e a classificare la foresta delle vulnerabilità.
Alcuni esempi sono
- Criticità del modulo/prodotto: è mission-critical (sensibilità o criticità)
- In quanti prodotti ho la vulnerabilità specifica?
- Esposizione all'esternalità di un servizio/componente
9. Esposizione alla conformità – Licenze: Sia le licenze software proprietarie che quelle open source sono importanti per convalidare la conformità della politica legale dell'organizzazione.
Concetto dei livelli di punteggio del rischio: aggiunta di metriche di rischio alle SBOM:
- Inizio con enumerazione CVE e punteggio CVSS basato sui dati SBOM.
- Utilizza e aggiungi contesto VEX per ridefinire le priorità delle criticità
- Valutare i CVE con un punteggio EPSS elevato (ovvero 0.6-1.0)
- Dai priorità all'elenco KEV – a prima l'indirizzo.
- Valuta in base al punteggio di reputazione OpenSSF (1-10): identifica le dipendenze rischiose.
- Analizzi i dati esposizione alla rete esterna (utilizzando il vettore CVSS)
- Valutare accumula rischio da parte del quantità di conteggio del prodotto per vulnerabilità.
- Valutare da parte del etichetta della criticità della SBOM del contenitore specifico per l'azienda.
- identifica violazione della conformità rischi nell'utilizzo dell'analisi delle dipendenze SBOM secondo la politica di licenza aziendale.
- Condividi e gestire i dati as attestazioni in una piattaforma collaborativa con flussi di lavoro verso altri sistemi come Jira e altri tramite API e leggibili dalla macchina.
Sfruttare le SBOM con punteggio di rischio per casi d'uso pratici:
- Valutazione continua delle vulnerabilità per i prodotti utilizzando parametri di rischio per dare priorità a un piano di lavoro di patching tra i prodotti.
- Confronta i prodotti fianco a fianco in base ai parametri di rischio.
- Confronta e approva gli aggiornamenti delle nuove versioni prima della distribuzione/rilascio.
- Tieni traccia del divario del debito tecnico utilizzando le soglie di punteggio di rischio per le versioni del prodotto.
- Crea un rapido report dei 50 principali rischi dei miei prodotti più critici.
- Analisi dell’impatto per accelerare la risposta all’incidente – nel caso in cui venga trovata in natura una vulnerabilità sfruttata attivamente. In questo caso, il tempo conta per identificare rapidamente il modo in cui subisco l'impatto e quale sarebbe il raggio di esplosione della mappa termica di questa esposizione.
Come utilizzare la piattaforma Scribe Hub per una gestione efficace del rischio:
- Piattaforma di gestione SBOM centralizzata – Creare, gestire e condividere SBOM insieme ai relativi aspetti di sicurezza: vulnerabilità, avvisi VEX, licenze, reputazione, sfruttabilità, scorecard, ecc.
- Costruisci e distribuisci software sicuro – Rileva manomissioni firmando e verificando continuamente il codice sorgente, le immagini del contenitore e gli artefatti in ogni fase delle pipeline CI/CD.
- Automatizza e semplifica la sicurezza SDLC – Controllare il rischio nella tua fabbrica di software e garantisci l'affidabilità del codice traducendo la sicurezza e la logica aziendale in policy automatizzate, applicate da guardrail
- Abilita la trasparenza. Migliora la velocità di consegna – Fornire ai team di sicurezza le capacità di esercitare le proprie responsabilità, semplificando il controllo di sicurezza senza ostacolare i risultati del team di sviluppo.
- Applicare le politiche. Dimostrare conformità - Monitora e applica le policy e la governance SDLC per migliorare la posizione di rischio del software e dimostrare la conformità necessaria per la tua azienda.
Due esempi di Scriba Hub vengono presentate le capacità di analisi del rischio:
Vulnerabilità mappate per SBOM, punteggio di rischio tramite dati CVSS, VEX, EPSS e KEV.
Serie temporali delle prestazioni della versione SBOM nel tempo che indicano MTTR il tempo medio necessario per riparare le vulnerabilità critiche identificate.
Sommario
Il punteggio di rischio basato su SBOM consente alle organizzazioni di valutare il rischio della catena di fornitura valutando fattori di rischio predefiniti e prevedendo potenziali rischi futuri associati a uno specifico prodotto software all'interno dell'azienda. Il punteggio di rischio funge da misura quantitativa per anticipare i rischi attuali e futuri relativi al software e ai suoi componenti.
Questa metrica di punteggio deriva da indicatori provenienti da SBOM, VEX, tra gli altri feed, e si allinea con il contenuto che supporta la gestione del rischio della catena di fornitura (SCRM). Quando si applica o si valuta un punteggio di rischio, è necessario prendere in considerazione fattori quali il contesto di utilizzo del software, il modo in cui si accede o si isola e i processi e i sistemi che supporta.
Scribe Hub funge da piattaforma collaborativa progettata per l'estrazione, la gestione, la raccolta di attestazioni e l'analisi del punteggio di rischio delle SBOM su larga scala. Questa piattaforma elabora in modo efficiente più feed di dati esterni per gestire le complessità di sistemi complessi e prodotti software.
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
