Negli ultimi anni sono state scritte molte parole a riguardo SBO – Distinta materiali del software. Con tutta questa visibilità, le persone sentono di sapere cosa è sufficiente spiegare: si tratta di un elenco di ingredienti software, è importante per la trasparenza e la sicurezza e aiuta a esporre le dipendenze transitorie. Tutto questo è vero.
Tuttavia, la SBOM non è così chiara come sembra. Per prima cosa, considera che per rimanere aggiornato ogni nuova versione o patch della libreria richiede il rilascio di una nuova SBOM. Spesso si modifica o si aggiorna solo una o due librerie alla volta in modo da poter semplicemente scomporre i nuovi ingredienti, aggiungerli alla SBOM e lasciare tutto il resto uguale, giusto?
E che dire del concetto di “noto-ignoto”? Se gli sviluppatori sanno che manca qualcosa, possono inserirlo come "noto-sconosciuto" e riempire gli spazi vuoti in seguito (o non riempirlo affatto).
Esistono anche artefatti software molto complessi che includono più elementi interconnessi, ciascuno dei quali è un artefatto software a sé stante. Ogni elemento ha spesso una propria SBOM separata e l'intera build può avere una SBOM maggiore e aggregata.
Tutto ciò dimostra che invece di un file SBOM chiaro e semplice ci si potrebbe ritrovare con una serie di elementi diversi e in continua evoluzione che è necessario mantenere costantemente il più aggiornati possibile.
Tutto ciò va bene, ma che differenza farebbe per qualcuno se una SBOM o parte di una SBOM non fosse accurata o aggiornata come potrebbe essere? Cosa potremmo fare per mantenere sia la provenienza della SBOM che la sua accuratezza?
In questo articolo esamineremo l'utilizzo della SBOM nelle scansioni e nella divulgazione delle vulnerabilità. Parleremo della firma crittografica e vedremo come la firma di una SBOM, o di parti di essa, la renda più utile come strumento di sicurezza e trasparenza. Parleremo anche dei metadati e del motivo per cui sono così importanti nella produzione SBOM e in altri artefatti, soprattutto quando si accede crittograficamente a un'attestazione.
Inizia da qui: cos'è comunque la firma crittografica?
Le firme crittografiche vengono utilizzate per verificare l'integrità e l'accuratezza di file o cartelle digitali. Un file firmato non può essere manomesso senza invalidare la firma e quindi verrebbe immediatamente scoperto non appena qualcuno tentasse di verificare il documento firmato.
Ciò rende le firme digitali uno strumento inestimabile nell’arsenale di sicurezza del software settore e sono già stati riscontrati numerosi usi per il semplice concetto di firma digitale o crittografica di risorse digitali.
Come funziona? Le firme digitali si basano sulla crittografia asimmetrica in cui un'entità ha due chiavi: una chiave privata e una chiave pubblica. Le due chiavi sono collegate tra loro in modo tale che un documento firmato con la propria chiave privata possa essere verificato utilizzando quella pubblica. Una verifica significherebbe sia che il documento non sia stato manomesso in alcun modo (anche la modifica di un solo bit renderebbe la firma inverificabile), sia dimostrare l'identità del firmatario, o almeno l'identità della chiave utilizzata.
Cosa stai facendo con quella SBOM?
Le SBOM non sono solo file lunghi e complicati contenenti informazioni sui componenti software. Sono la tua porta d'accesso per sapere esattamente quali componenti compongono il tuo artefatto software. È necessario conoscere l'elenco completo dei componenti poiché anche se potresti pensare di sapere esattamente cosa hai incluso, è probabile che con ogni libreria aggiunta che hai fornito in numerose dipendenze nascoste e temporanee, ognuna delle quali potrebbe essere portatrice di una vulnerabilità o sfruttarla è ora incluso nel software che spedisci ai tuoi clienti.
Una volta che hai una SBOM e l'elenco completo degli ingredienti, puoi scansionare l'elenco confrontandolo con i database delle vulnerabilità note e vedere quali vulnerabilità sono incluse nel tuo software. Ma questo è solo l'inizio. Come sa chiunque abbia eseguito una scansione di vulnerabilità, i risultati anche di una semplice scansione degli artefatti possono facilmente essere nell'ordine di centinaia (o più) di vulnerabilità.
È qui che inizia il duro lavoro, nel mappare ciascuna vulnerabilità, vedere se potrebbe essere sfruttabile nella specifica composizione del software, documentare tali informazioni e gestire le vulnerabilità sfruttabili applicando patch e risolvendole, preferibilmente in ordine di pericolo che rappresentano (live gli exploit in natura sono più pericolosi di un exploit teorico che non è mai avvenuto).
Tutto questo lavoro, la documentazione e la risoluzione delle vulnerabilità sono importanti per te come produttore di software, ma sono importanti anche per i tuoi clienti, i tuoi partner e potenziali revisori.
Vogliono sapere che sei consapevole delle potenziali vulnerabilità e che sei al corrente di tutto, applicando patch e correggendo i difetti, in modo che questi non abbiano un impatto su LORO come tuoi clienti o partner.
Dato che il momento in cui esegui una scansione è importante a questo proposito a causa del fatto che nuove vulnerabilità vengono costantemente alla luce, firmare la tua SBOM insieme ai metadati di QUANDO è stata creata è un ottimo modo per dimostrare che sei davvero al top del tuo elenco delle vulnerabilità.
In questo modo puoi dimostrare che eri a conoscenza di una vulnerabilità in anticipo e che non è rilevante (utilizzando un file VEX advisory), che non è presente in una determinata versione o che non esisteva nemmeno nel momento in cui hai rilasciato l'ultima versione.
Dove devo firmare?
Ora sostituiamo il semplice file dell'elenco degli ingredienti con uno dei casi d'uso più complessi descritti all'inizio dell'articolo. Una volta combinate più SBOM per formare una versione aggregata più grande per descrivere l'intero artefatto, firmare e verificare ogni singola parte di quella versione aggregata diventa ancora più importante. Supponiamo che tu stia creando una nuova versione di un artefatto software complesso. In questa nuova versione, l'unica cosa che è cambiata è la parte 1 di un artefatto in 3 parti. Le altre due parti rimangono esattamente le stesse. Perché dovresti sprecare tempo e risorse nella creazione dell'SBOM completo in 3 parti, nella scansione di tutte e 3 le vulnerabilità e nella mappatura di tutte e 3 gli exploit rilevanti? Le uniche modifiche erano nella parte 1, quindi è l'unica in cui dovresti inserire il lavoro. Se hai firmato tutte e 3 le SBOM e le scansioni di vulnerabilità l'ultima volta che le hai create, puoi includere le informazioni delle altre due parti sapendo che non potrebbe sono stati modificati. Potrai quindi dimostrare in qualsiasi momento che le SBOM per le parti 2 e 3 sono identiche alle versioni originali. Ovviamente puoi ripetere le scansioni se sei preoccupato per nuove vulnerabilità, ma dipende completamente da te e dal tuo software analisi del rischio.
Essere in grado di dimostrare ai propri clienti, partner e revisori quando e con quale frequenza sono state create le SBOM e analizzate le vulnerabilità è utile per numerosi motivi. Non ultimo, potrebbe essere utilizzato in tribunale per dimostrare che non sei responsabile per il danno di un exploit poiché hai fatto tutto il necessario per essere protetto, ottenendo così un porto sicuro.
Dove andare da qui
Come affermato in precedenza, uno dei problemi legati alla firma digitale di artefatti o file software è la difficoltà di gestire i sistemi di gestione delle chiavi. Una volta eliminato questo fastidio utilizzando qualcosa come Sigstore per bypassare l'uso di una PKI tradizionale e rendere automatico il flusso di firma e verifica, ci sono davvero pochi motivi per non utilizzare questo strumento di sicurezza. Se consideri che l'identità utilizzata per firmare un file o un artefatto può essere utilizzata anche in una policy che verifica la sicurezza della tua pipeline CI/CD, dovresti essere ancora più motivato a iniziare a firmare quasi tutto ciò che vedi.
Firmare i file con i relativi metadati può aiutarti a verificare l'ora e il luogo della loro origine, nonché la persona e il sistema in cui sono stati creati, tutte informazioni rilevanti se considerate attraverso le lenti di uno specialista della sicurezza. Essere in grado di dire che la persona, il sistema e l'ora corrispondono all'azienda e alla pipeline in cui è stato creato il software è una buona idea quando una semplice sostituzione può presentare una contraffazione convincente firmata, fino a quando non viene controllata la persona che canta.
Considerando che lo strumento che suggerirei per firmare e verificare le prove è gratuito, non dovresti davvero avere scuse. Dai un'occhiata al nostro articolo completo su Valente – il nostro strumento Validation Integrity per vedere cos'altro puoi fare con esso e iniziare a firmare le tue SBOM e altre prove generate oggi stesso.
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
