Il 22 marzo il NIST ha rilasciato la versione finale del SSDF 1.1 (Secure software development framework).
Il quadro è stato inizialmente pubblicato nel settembre 2021 come bozza. Tutte le pratiche e i compiti di alto livello rimangono gli stessi, con molte differenze incentrate sui vari esempi forniti.
Qual è il quadro normativo NIST SP 800-218? L'SSDF consolida raccomandazioni di best practice di lunga data per lo sviluppo di software sicuro. Il suo approccio personalizzabile e indipendente dal settore è costruito per facilitare le comunicazioni tra reparti (e produttore/acquirente) per aiutare a definire obiettivi strategici e valutare le lacune attuali.
Il NIST raccomanda di bilanciare il rischio con i costi, la fattibilità e l’applicabilità al momento di decidere quali pratiche implementare. L'automazione è una caratteristica chiave da considerare con l'obiettivo desiderato di automatizzare il maggior numero possibile di controlli e processi che promuovono la sicurezza del software.
Differenze tra la versione finale e quella in bozza:
Verifica dell'integrità – Quando si parla di vulnerabilità, ci si concentra maggiormente sulla verifica dell’integrità quando guardi sia il tuo codice che le librerie/prodotti acquisiti da fonti esterne.
Attestazioni immutabili - La responsabilità dell’implementazione delle pratiche può essere distribuita tra diverse organizzazioni, soprattutto se si considera la complessità delle catene di fornitura del software. La visibilità diminuisce in modo significativo man mano che si va a monte o a valle della catena. Ecco perché il NIST raccomanda di codificare la responsabilità condivisa che coinvolge sia i fornitori che i consumatori di una piattaforma/servizio in un contratto o accordo. Dovrebbe essere chiaro quale parte è responsabile di ciascuna pratica e compito e in che modo ciascun fornitore attesterà la propria conformità all'accordo. Qui vale l'assioma “fiducia ma verifica”: attestazioni immutabili che possono essere facilmente condivisi tra produttori e acquirenti di software sono fondamentali per aumentare la fiducia di tutte le parti interessate nella catena di fornitura del software.
Coinvolgimento della comunità open source – Il NIST afferma che il lavoro futuro probabilmente assumerà la forma di casi d’uso specifici e con cui intende collaborare la comunità open source. Considerando che la maggior parte dei prodotti di codice commerciale in uso oggi includono significativi elementi di codice open source, è naturale includere la comunità open source nella pianificazione e implementazione della sicurezza del ciclo di vita del software.
Punteggi di gravità della vulnerabilità come KRI (Key Risk Indicator) – Un altro cambiamento in atto riguarda i punteggi di gravità come indicatore chiave. Sapendo che gran parte del personale addetto alla sicurezza informatica soffre di affaticamento da allerta, è logico che ciascuna organizzazione definisca la scala del punteggio di vulnerabilità più adatta e il trattamento specifico che ciascuno di tali punteggi merita.
Meno accesso umano, più automazione – Il NIST incoraggia a ridurre al minimo l’accesso umano diretto ai sistemi di toolchain, come i servizi di costruzione. Più persone hanno accesso, più errori potrebbero verificarsi. Ciò rientra, ancora una volta, nella stessa linea della raccomandazione per una maggiore automazione.
SBOM con integrità – Quando si discute della SBOM (Software Bill of Materials), il NIST raccomanda di impiegare una forte protezione per l'integrità dell'artefatto, oltre a fornire ai destinatari un modo per verificare tale integrità. I destinatari possono essere persone sia interne che esterne all'organizzazione, quindi è opportuno utilizzare un sistema di terze parti per condividere SBOM sicure.
Integrità binaria e codice sorgente – Se non è possibile confermare l'integrità o la provenienza dei file binari acquisiti, si consiglia di creare nuovamente tali file binari dal codice sorgente. Ciò presuppone che tu possa verificare l'integrità e la provenienza del codice sorgente. È responsabilità di tutti gli anelli della catena di fornitura del software fornire una prova verificabile dell'integrità, tramite firme digitali o altri meccanismi come una SBOM.
Sommario
Nel complesso, il NIST ritiene che “le pratiche, i compiti e gli esempi di implementazione dell'SSDF rappresentano un punto di partenza da considerare. Sono pensati per essere modificati, personalizzati e per evolversi nel tempo”.
L'SSDF non è una lista di controllo da seguire, ma fornisce invece indicazioni per pianificare e implementare un approccio basato sul rischio per proteggere lo sviluppo del software.
A differenza delle normative statunitensi basate sulla legge, l’SSDF sarà basato sulle imprese: il governo farà leva sul proprio potere d’acquisto per convincere il mercato ad aderire a questo nuovo quadro di migliori pratiche. Se non puoi dimostrare di aderire al quadro, non sarai preso in considerazione per i contratti governativi. Probabilmente vedremo un effetto a catena in cui le organizzazioni che intendono richiedere contratti governativi richiederanno che anche tutti i loro venditori e fornitori si conformino, e così via lungo la catena di fornitura del software.
Per saperne di più sulle nuove normative e sulla SSDF, consulta il nostro webinar su "Demistificazione delle nuove normative sulla sicurezza informatica nel 2022".
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
