Garanzia continua: una pratica integrale per la sicurezza della catena di fornitura del software

La sezione è il secondo di una serie di articoli che esaminano le nuove linee guida NIST SP 800-218. Il primo articolo può essere trovato qui.

Garanzia continua:
Una pratica integrale per la sicurezza della catena di fornitura del software

Come abbiamo discusso nel nostro articolo precedente, le linee guida stabilite dal National Institute of Standards and Technology (NIST) degli Stati Uniti modificheranno radicalmente il modo in cui i prodotti e i servizi software vengono forniti al governo degli Stati Uniti. 

specificamente, NISTSP800-218 stabilisce una serie di pratiche di sviluppo software sicure di alto livello che devono essere integrate in ogni ciclo di vita dello sviluppo software (SDLC). Si prevede che l’incorporazione di queste pratiche lungo tutta la catena di fornitura del software promuova prodotti e servizi più sicuri da fornire non solo al governo degli Stati Uniti, ma, in ultima analisi, a tutti i settori e in tutto il mondo. 

In questo articolo esaminiamo il ruolo fondamentale della Continuous Assurance (CA) nel soddisfare questi nuovi requisiti. 

Panoramica: cos'è la garanzia continua e come funziona? 

CA è un concetto e un insieme di soluzioni in divenire, complementari ai concetti già familiari di integrazione continua, sviluppo e test della disciplina DevOps. CA raccoglie in modo granulare prove su tutti gli eventi nel ciclo di vita dello sviluppo, inclusa la creazione e la distribuzione del prodotto, che potrebbero influire sulla sicurezza finale del prodotto software. È un mezzo con cui i consumatori di software (come utenti, acquirenti e altri soggetti interessati al rischio) possono controllare il rischio derivante dai prodotti che utilizzano. 

Oggi le aziende applicano una miriade di strumenti di sicurezza per migliorare la protezione dei prodotti software che sviluppano. Tuttavia, raramente utilizzano una politica generale per stabilire lo standard per l’uso coerente di questi strumenti. Inoltre, se i consumatori di prodotti software appartengono a un'altra organizzazione, non dispongono delle informazioni o degli strumenti necessari per stabilire il livello di rischio che corrono. In poche parole, questo è il punto cieco della catena di fornitura del software che CA mira a dissipare. 

Il risultato immediato di CA è un mezzo per garantire che i prodotti software non siano stati manomessi e che durante lo sviluppo siano stati eseguiti test critici relativi alla sicurezza, ma c'è ancora molto da guadagnare da ciò.

Per contrastare la manomissione da parte di aggressori o l'insabbiamento da parte dei fornitori di componenti nascosti di dubbia origine, ad esempio provenienti da paesi vietati, CA trasforma le prove raccolte in un'attestazione a prova di manomissione firmando crittograficamente le informazioni e archiviandole in un archivio immutabile in un ambiente sicuro e isolato. 

Rendendo le prove raccolte leggibili dalle macchine, un motore di policy può convalidare continuamente le norme o le regole stabilite dalle parti interessate al rischio per ogni versione o aggiornamento del prodotto. In questo modo, le parti interessate possono essere certe della conformità di un prodotto ai relativi standard di sicurezza. 

Concettualmente, l'utilizzo della metodologia CA migliora anche la qualità del prodotto. Controllando lo standard di base per la revisione del codice e i test di sicurezza con una politica centrale per le pipeline di un particolare prodotto, le incoerenze e le modifiche ad hoc ai processi ordinati verrebbero eliminate.

Perché continuo?

Le configurazioni di sicurezza nel processo di sviluppo non sono una novità. Ad esempio, potresti aver già stabilito che nessun file binario andrà in produzione senza la scansione delle vulnerabilità. 

Oggi i cicli di distribuzione del software diventano sempre più brevi. Di conseguenza, gli angoli potrebbero essere tagliati. La revisione del codice potrebbe essere saltata oppure i test di sicurezza o le procedure importanti potrebbero non essere eseguiti. Inoltre, vengono continuamente segnalati nuovi CVE ed exploit e vengono costantemente pubblicate nuove versioni dei componenti. 

Tutti questi fattori combinati ci impongono di testare continuamente i componenti rispetto allo standard di sicurezza stabilito per verificare che i processi utilizzati siano ancora conformi alla politica di sicurezza. 

Le politiche di sicurezza sono determinate dal detentore del rischio. Ecco alcuni esempi di regole politiche che potrebbero essere impiegate: 

• Consenti l'uso di pacchetti open source solo da un elenco approvato
• Richiedi due revisori per ogni richiesta pull.
• Verificare che tutti i componenti proprietari nell'artefatto finale possano essere ricondotti ai repository del controllo del codice sorgente.

Alzare la barra di sicurezza del software

Gli attacchi alla catena di fornitura del software modificano il comportamento previsto dei componenti software. Oggi questi attacchi si basano sulla mancanza di capacità sia dei consumatori che dei produttori di software di verificare l'integrità dei componenti software. 

Tuttavia, firmando prove provenienti da ogni parte del ciclo di vita dello sviluppo, dalle dipendenze open source al prodotto finale, e confrontando continuamente queste prove con quanto previsto, gli aggressori si troveranno ad affrontare maggiori difficoltà quando tentano di manomettere file, strumenti o comportamento previsto della pipeline CI/CD.     

Raccolta di prove: esempi e raccomandazioni

Ecco alcuni esempi di prove che possono essere raccolte lungo l’SDLC:

Ed ecco i tipi di politiche che possono essere utilizzate, utilizzando queste prove:

Il futuro della garanzia continua del codice

Nel Secure Software Development Framework di febbraio 2022 (SSDF), il NIST suggerisce che l'implementazione degli strumenti di sicurezza nel processo di sviluppo dovrebbe basarsi in modo significativo sull'automazione. Il nostro approccio alla garanzia continua è coerente con questa raccomandazione. 

Anche se sei sicuro che tutte le misure e le misure di sicurezza siano state configurate correttamente, devi comunque fornire i mezzi per garantire a clienti e fornitori che la tua politica di sicurezza sia stata applicata in modo coerente e continuo. Tutte le parti interessate, i produttori di software (sviluppatori o venditori) e i consumatori (utenti o acquirenti) dovrebbero essere in grado di esaminare e verificare continuamente e automaticamente le prove provenienti da ciascun anello della catena di fornitura del software per assicurarsi che i propri criteri di sicurezza siano soddisfatti. 

La fiducia nella catena di fornitura del software è attualmente bassa e ciò costituisce una costante fonte di preoccupazione per tutte le parti interessate. Aumentare la visibilità delle misure di sicurezza che sono state implementate e fornire prove della Continuous Code Assurance sono fondamentali per ricostruire la fiducia nella catena di fornitura del software e produrre prodotti verificabilmente più sicuri.