Sicurezza CI/CD: sicurezza della pipeline CI/CD

La pipeline CI/CD (integrazione continua/consegna continua) è il fondamento su cui vengono costruiti tutti i processi DevOps. Per questo motivo, rendere sicure le pipeline CI/CD in ogni fase e per tutti gli strumenti e ambienti che le compongono dovrebbe essere una priorità per le aziende che utilizzano i workflow DevOps.

Continua a leggere per scoprire perché la sicurezza CI/CD è importante e quali sono le migliori prassi per applicarla in tutta la pipeline.

Cos’è la sicurezza di CI/CD?

La sicurezza CI/CD è un processo a più fasi che ha lo scopo di individuare e mitigare i rischi per la sicurezza in ogni punto della pipeline CI/CD.

Le specifiche della sicurezza CI/CD variano da team a team in base alle caratteristiche uniche di ciascuna operazione CI/CD del team. Sebbene le pipeline CI/CD includano almeno alcune fasi fondamentali (ovvero la gestione, la compilazione, la verifica e l’utilizzo del codice sorgente) alcune di esse sono caratterizzate da fasi aggiuntive che aumentano la complessità e i rischi per la sicurezza. Allo stesso modo, le pipeline CI/CD che si riferiscono ad ambienti produttivi diversi (come i server Windows e Linux) sono più complesse e pongono maggiori rischi per la sicurezza rispetto a quelle che eseguono applicazioni in un solo tipo di ambiente.

L’approccio alla sicurezza CI/CD, dunque, dipende dalla struttura esatta dei processi CI/CD coinvolti e dagli strumenti utilizzati per portarli a termine. Ciononostante, quando si rende sicura una pipeline CI/CD, l’interesse principale dovrebbe essere garantire che, indipendentemente dal percorso effettuato dal codice lungo la pipeline, tutti i potenziali rischi siano mitigati in ogni fase del processo.

Minacce alla sicurezza CI/CD

Oltre a comprendere in che modo funziona una pipeline, è anche necessario riconoscere i diversi tipi di minacce che potrebbero compromettere le operazioni CI/CD, al fine di adottare le misure più adeguate per difendersi.

Sebbene sia impossibile individuare ogni tipo di potenziale rischio per la sicurezza CI/CD prima che si verifichi, ecco alcuni tra gli esempi più comuni:

• Codice non sicuro importato in una pipeline CI/CD da una fonte terza, ad esempio un progetto open source.
• Accesso non autorizzato a repository di codice sorgente o strumenti di compilazione che potrebbero consentire agli hacker di inserire codice dannoso in un’applicazione.
• Violazione di un ambiente dev/test in cui l’autore di un attacco disabilita importanti controlli di sicurezza, impedendo al team di rilevare violazioni in fase di test della pipeline.
• Gestione non sicura di informazioni segrete nella pipeline dovuta a pratiche quali l’hard coding delle password in un modello IaC. Chi accede a queste informazioni potrebbe utilizzarle per violare la sicurezza.

Come rendere sicura una pipeline CI/CD

Dal momento che le minacce CI/CD interessano diverse fasi della pipeline e diversi livelli dello stack del software, la sicurezza della pipeline CI/CD richiede un approccio su più fronti. È necessario utilizzare strumenti e processi in grado di rilevare minacce di diverso tipo.

Di seguito presentiamo le principali categorie di strumenti e le migliori prassi che aiutano a rilevare e gestire i rischi per la sicurezza CI/CD.

Analisi della composizione del software

L’analisi della composizione del software, o SCA, consiste nella scansione del codice sorgente allo scopo di individuare le vulnerabilità che si originano da moduli o cataloghi di terze parti, ad esempio quelli importati da un progetto open source. Gli strumenti SCA sono in grado di effettuare una scansione dei repository del codice sorgente all’avvio della pipeline CI/CD e di avvertire in caso di dipendenze che, se lasciate irrisolte, potrebbero comportare vulnerabilità nella sicurezza dell’applicazione.

Test statico della sicurezza delle applicazioni

Il test statico della sicurezza delle applicazioni, o SAST, completa l’analisi SCA verificando le eventuali vulnerabilità del codice sorgente scritto direttamente dall’autore di un’applicazione. In altre parole, mentre l’analisi SCA permette di individuare le vulnerabilità di codici di terze parti in base a un database di vulnerabilità conosciute, l’analisi SAST effettua un’analisi all’origine del codice personalizzato al fine di rilevare eventuali problemi per la sicurezza quali una convalida degli input non adeguata.

Pertanto, effettuando sia l’analisi SAST che l’analisi SCA all’inizio della pipeline CI/CD, sarà possibile ottenere un doppio livello di protezione dai rischi posti dal codice sorgente.

Controllo degli accessi CI/CD

Ricorrere al controllo degli accessi per gestire gli strumenti e le risorse autorizzate ad accedere alla pipeline CI/CD è fondamentale per evitare attacchi nel caso in cui sia stato inserito del codice pericoloso all’interno dell’ambiente di sviluppo, che è il vettore utilizzato nell’ormai famigerato attacco a SolarWinds, annunciato nel 2020.

Per gestire questo tipo di rischi, ogni strumento all’interno della pipeline CI/CD dovrebbe essere protetto da password, chiavi di accesso o altri tipi di controllo, inoltre l’accesso dovrebbe essere consentito su base individuale solo ai membri del team che hanno un’esigenza specifica. Sebbene possa sembrare allettante accordare l’accesso a tutte le risorse CI/CD a ogni sviluppatore e ad ogni tecnico, questa non è prassi consigliata. Devia infatti dal principio dei privilegi minimi e moltiplica le possibilità che un account violato offra agli hacker le chiavi di accesso all’intero regno CI/CD.

Gestione delle informazioni segrete e CI/CD

Informazioni segrete quali password e chiavi di accesso sono spesso richieste in molte fasi dei processi CI/CD per integrare o compilare il codice, utilizzare applicazioni in fase di test o produzione, eccetera.

Tipicamente, il modo più facile per condividere queste informazioni è scriverle come hard coded nei file di configurazione CI/CD o nei modelli IaC utilizzati dai team negli ambienti applicativi. Ma, anche in questo caso, la strada più semplice non è quella più sicura. Così impostate, le informazioni possono essere acquisite da chiunque sia in grado di visualizzare i file di configurazione o i modelli IaC, il che pone un notevole rischio per la sicurezza.

Una migliore soluzione è utilizzare un sistema di gestione delle informazioni segrete per archiviare i dati sensibili e condividerli solo se necessario durante le operazioni CI/CD.

Scansione dei registri

Se la pipeline CI/CD prevede applicazioni che fanno uso di container, è possibile aggiungere ancora un altro livello di protezione effettuando una scansione automatica delle immagini dei container non appena raggiungono i registri. La scansione dei registri consente di verificare le vulnerabilità dei container per permettere al team di individuare codici dannosi che potrebbero aver superato i controlli di sicurezza svolti nelle fasi precedenti della pipeline CI/CD.

La scansione dei registri si rivela particolarmente importante dato che alcune vulnerabilità potrebbero essere introdotte non nelle fasi iniziali della pipeline, bensì come parte di dipendenze che vengono incorporate a un container in una fase successiva. Come risultato, strumenti quali le analisi SCA e SAST, che analizzano esclusivamente il codice, non individuano tali vulnerabilità. Ma lo fa la scansione dei registri, almeno nella maggior parte dei casi.

Sicurezza di runtime

La sicurezza di runtime, ovvero l’individuazione di minacce attive nelle applicazioni in esecuzione, aiuta a gestire le minacce durante l’importantissima fase finale della pipeline CI/CD: la messa in produzione. È anche possibile applicare la sicurezza di runtime agli ambienti dev/test come parte di una strategia di sicurezza “shift left”.

La sicurezza di runtime utilizza diversi strumenti e fonti di dati quali i registri di applicazioni, le metriche di rete e i registri di controllo. L’approccio alla sicurezza di runtime varia in base al tipo di ambiente (se utilizza container, qual è l’orchestrazione impiegata, eccetera), ma il suo scopo fondamentale dovrebbe essere sempre rilevare le minacce attive prima che si espandano.

Una pipeline CI/CD non sicura porterà inevitabilmente ad applicazioni non sicure. Gestendo i rischi per la sicurezza in tutte le fasi della pipeline attraverso prassi quali il controllo degli accessi, la gestione delle informazioni segrete e la scansione dei registri, sarà possibile minimizzare il rischio che codice non sicuro si introduca nella pipeline.