Gestione del rischio della software supply chain

Gestione del rischio e sicurezza

La sicurezza della software supply chain è l'insieme dei controlli tecnici: SBOM, dipendenze fissate, build con restrizioni. La gestione del rischio si colloca al di sopra. Si chiede da quali fornitori e componenti dipende la Sua azienda, che cosa succede se uno viene meno e se ha concentrato i Suoi sforzi nel posto giusto.

Quali sono i rischi?

Rischio	Esempio	Controllo principale
Componenti vulnerabili	Un difetto in una libreria molto diffusa	SBOM e monitoraggio continuo
Componenti malevoli	Un pacchetto dirottato, o typosquatting	Valutazione, adozione ritardata, limiti al traffico in uscita
Progetti abbandonati	Una dipendenza con un solo maintainer che si è dedicato ad altro	Controlli sullo stato di salute e un piano di sostituzione
Rischio legato alle licenze	Un componente copyleft in un prodotto proprietario	Policy sulle licenze
Compromissione della build	Una GitHub Action dirottata raggiunge i Suoi secret	Pinning, isolamento, privilegi minimi
Rischio legato ai fornitori	Il prodotto o l'aggiornamento di un vendor viene compromesso	Valutazione, contratti, SBOM dei fornitori
Rischio normativo	Un cliente o una legge richiede evidenze che Lei non è in grado di produrre	Registri conservati per release

Un processo in sei passaggi

1. Costruisca l'inventario. Elenchi i prodotti che realizza e il software che acquista. Per ciò che sviluppa, conservi una SBOM per release. Non si può valutare ciò che non si vede.
2. Ordini in base a ciò che conta. Una libreria nel Suo servizio di pagamento non equivale a una in uno strumento interno. Classifichi i prodotti per esposizione, dati e impatto sul business.
3. Valuti i rischi. Esamini vulnerabilità, stato di salute dei progetti, licenze e il modo in cui ogni fornitore gestisce la sicurezza. Lo faccia in profondità per il livello più alto e in modo leggero per tutto il resto.
4. Li tratti. Per ogni rischio, decida se correggere, sostituire, aggiungere un controllo o accettare. Un rischio accettato ha bisogno di un responsabile e di una data di revisione.
5. Monitori di continuo. Il rischio cambia senza alcuna modifica da parte Sua, ad esempio quando viene pubblicato un advisory o un maintainer se ne va. Le revisioni annuali non lo colgono.
6. Riferisca. Fornisca alla direzione una vista sintetica: rischi principali, esposizione nel tempo e che cosa è stato accettato. Clienti e auditor chiederanno i dettagli.

Valutare i fornitori

I soli questionari Le dicono ciò che un fornitore afferma. Chieda elementi che mostrino ciò che fa:

• Una SBOM del prodotto, con un formato dichiarato e un modo per ricevere gli aggiornamenti
• Come gestisce le vulnerabilità e con quale rapidità informa i clienti
• Un contatto per la sicurezza e una policy di divulgazione
• Come compila le release e se può dimostrarne la provenienza
• Per quanto tempo una versione riceve correzioni di sicurezza
• Certificazioni e report di audit che coprano il prodotto che sta acquistando

Inserisca queste aspettative nei contratti. È molto più facile richiedere una SBOM o un tempo di notifica alla firma che dopo un incidente.

Framework da seguire

• NIST SP 800-161 è il riferimento principale per la gestione del rischio informatico nella supply chain, o C-SCRM. Si applica a ogni livello di un'organizzazione e integra il rischio della supply chain nella gestione del rischio più ampia.
• Il NIST SSDF copre le pratiche di sviluppo sicuro, il che lo rende una buona base per ciò che chiede ai fornitori e a se stesso.
• SLSA offre un linguaggio comune per descrivere quanto è affidabile una build.
• ISO/IEC 27001:2022 comprende controlli per la sicurezza della supply chain ICT (Allegato A 5.21) e per le vulnerabilità tecniche (8.8). Non richiede una SBOM, ma le SBOM sono una buona evidenza per questi controlli.
• NIS2 indica la sicurezza della supply chain come misura obbligatoria per i soggetti interessati, all'articolo 21(2)(d).

Come misurarla

Scelga poche misure che portino a decisioni:

• Quota di prodotti con una SBOM per la release corrente
• Tempo per rispondere a "siamo colpiti?" per una nuova vulnerabilità critica
• Finestra di esposizione: per quanto tempo una versione vulnerabile è stata in produzione
• Quota di fornitori del livello più alto valutati nell'ultimo anno
• Numero di rischi accettati oltre la data di revisione

Dove CRACI aiuta

CRACI fornisce a un programma di gestione del rischio i dati che di solito mancano per il software che si sviluppa. Registra ciò che ogni build GitHub Actions ha scaricato, comprese le licenze dichiarate, in SBOM che Lei può conservare per release e condividere in CycloneDX o SPDX. Monitora ciò che è stato distribuito, mostra quali build contenevano un pacchetto vulnerabile, così può vedere il periodo in cui è stato colpito, e può applicare la policy sulle licenze e bloccare le build con i policy gate. Veda la sicurezza della software supply chain con CRACI e il confronto tra gli strumenti.

La valutazione dei fornitori e il registro dei rischi restano affidati ai Suoi strumenti di governance e al Suo team.

Gestione del rischio della software supply chain: domande frequenti

Che cos'è la gestione del rischio della software supply chain?

È il modo in cui un'organizzazione identifica, valuta e riduce il rischio derivante da software che non ha scritto, compresi pacchetti open source, prodotti commerciali, fornitori SaaS e strumenti di build.

Che cos'è il C-SCRM?

C-SCRM sta per cybersecurity supply chain risk management, il termine usato dal NIST. NIST SP 800-161 è la sua guida principale e spiega come individuare, valutare e ridurre i rischi informatici lungo la supply chain a ogni livello di un'organizzazione.

Quali sono i maggiori rischi della software supply chain?

Componenti open source vulnerabili e malevoli, sistemi di build e strumenti CI compromessi, progetti abbandonati, problemi di licenza e fornitori che subiscono violazioni.

In che cosa si differenzia dalla gestione del rischio di terze parti?

La gestione del rischio di terze parti di solito esamina i vendor in quanto aziende. La gestione del rischio della software supply chain scende fino ai componenti e ai processi di build, compresi i progetti open source senza un vendor alle spalle.

Chi ne è responsabile?

In genere la direzione della sicurezza o del rischio definisce il programma, la product security è responsabile di ciò che l'azienda sviluppa e l'ufficio acquisti o la gestione dei vendor di ciò che acquista. I team di engineering correggono ciò che viene trovato.