Le condutture CI/CD sono notoriamente opache riguardo a ciò che avviene esattamente al loro interno. Anche se sei tu a scrivere il file di configurazione YAML (l'elenco delle istruzioni della pipeline) come puoi essere sicuro che tutto avvenga esattamente come descritto? Quel che è peggio, la maggior parte delle condutture sono completamente effimere, quindi anche se succede qualcosa di brutto non rimangono tracce.
In parole povere, una pipeline è un modo automatizzato per testare, creare e pubblicare il tuo software, app o artefatto. Tali condutture stanno diventando sempre più comuni e complicate. Le pipeline funzionano alla grande nel far sì che i team lavorino più velocemente, per fornire risultati più coerenti e prevedibili durante la produzione del loro artefatto software. L'importanza di automatizzare questi processi diventa ancora più chiara se si considera che le aziende più grandi potrebbero avere centinaia di pipeline orchestrate che dipendono l'una dall'altra, quindi è fondamentale che tutto funzioni senza intoppi e senza intoppi.
Essendo l'anello finale del processo di sviluppo tra gli sviluppatori e l'utente o cliente finale, ritengo che non ci sia abbastanza attenzione su come tali processi automatizzati potrebbero essere utilizzati come potenziali vettori di attacco. L'accesso a una pipeline di creazione potrebbe consentire ad autori malintenzionati non solo di penetrare nel sistema dell'azienda produttrice, ma anche di modificare potenzialmente l'artefatto risultante in modo tale da influenzare tutti i futuri utenti, creando così un enorme raggio di esplosione spesso descritto come un attacco alla catena di fornitura del software.
In un articolo precedente, abbiamo discusso i principi che dovrebbero guidarti proteggere la pipeline CI/CD. In questo articolo tratterò alcuni dei potenziali punti deboli più comuni in una pipeline CI/CD e offrirò alcune opzioni di correzione. Per i nostri scopi non importa quali strumenti o sistemi di automazione stai utilizzando: i principi di sicurezza sono ancora validi, devi solo trovare lo strumento giusto per proteggere quella sezione della tua pipeline.
Padroneggiare l'arte del CI/CD: gli elementi chiave che non puoi ignorare
Condutture diverse hanno elementi diversi e utilizzano strumenti diversi. Gli elementi su cui ho scelto di concentrarmi sono rilevanti per quasi tutte le pipeline, pertanto la protezione di questi elementi può essere considerata una procedura consigliata, indipendentemente dall'SCM, dagli strumenti o dalla configurazione di sicurezza esistente.
Gestione segreta – i segreti sono solitamente stringhe o token utilizzati per connettere il software o la pipeline ad altre risorse. Un esempio comune sono le chiavi API utilizzate per connettere il tuo codice alle risorse AWS come un bucket S3. La maggior parte delle persone sa già che dovrebbe tenere nascosti questi segreti e non includerli come testo semplice in un repository aperto. Le cose sono un po' più complicate all'interno di una pipeline CI/CD. Di solito, la pipeline necessita dell'accesso a questi segreti per accedere alle risorse e alle informazioni che rappresentano. Ciò significa che chiunque abbia accesso a ciò che accade all'interno della tua pipeline potrebbe potenzialmente vedere e copiare i tuoi segreti. Un modo per mantenere i tuoi segreti al sicuro anche all'interno della tua pipeline è utilizzare uno strumento di gestione dei segreti come Deposito della Hashicorp. Tali strumenti non solo possono offuscare i tuoi segreti anche all'interno della tua pipeline, ma rendono molto più semplice la rotazione dei tuoi segreti in modo che tu possa modificarli regolarmente rendendo inutile il furto di segreti da una pipeline. Indipendentemente dallo strumento di gestione dei segreti che scegli di utilizzare, la rotazione regolare dei tuoi segreti può essere considerata una buona pratica di sicurezza da adottare.
Esecuzione di una pipeline avvelenata (DPI) - L'esecuzione di pipeline avvelenate (PPE) è una tecnica che consente agli autori delle minacce di "avvelenare" la pipeline CI, modificando in effetti i passaggi della pipeline o il loro ordine come definito nel file di istruzioni della pipeline. La tecnica abusa delle autorizzazioni nei repository di gestione del codice sorgente (SCM) per manipolare il processo di compilazione. Consente di inserire codice o comandi dannosi nella configurazione della pipeline di compilazione, avvelenando la pipeline per eseguire codice dannoso durante il processo di compilazione. A meno che tu non verifichi il file di istruzioni della pipeline prima di ogni build, molto probabilmente sarai all'oscuro del fatto che le tue build non vengono più eseguite come specificato. Anche un cambiamento minuscolo, come chiamare una libreria piuttosto che un'altra, può avere effetti di vasta portata, come l'inclusione di backdoor o crypto miner nel prodotto finale.
Uno dei modi per evitare il PPE è verificare che il file di istruzioni della pipeline non sia modificato. Puoi firmare crittograficamente il file e aggiungere la verifica della firma come primo passaggio di ogni pipeline. Uno strumento che puoi utilizzare per firmare e verificare i file è Valente, uno strumento pubblicato da Scribe Security. Qualunque sia lo strumento di verifica del segno che finirai per utilizzare, l'idea è quella di assicurarti che l'integrità del tuo file di istruzioni rimanga intatta.
Avvelenamento da cache/dipendenze – I flussi di lavoro della pipeline CI/CD vengono spesso utilizzati per specificare azioni particolari che devono essere eseguite. Ogni flusso di lavoro è costituito da una serie di uno o più lavori, caratterizzati come una sequenza di azioni. La maggior parte dei flussi di lavoro non condivide le risorse per motivi di sicurezza. Esistono tuttavia soluzioni alternative per quando diventa necessario condividere le risorse. Una cache a cui tutti i flussi di lavoro possono accedere allo stesso modo è una di queste soluzioni alternative. Poiché la cache è condivisa da più flussi di lavoro, è sufficiente un'infrazione in un flusso di lavoro con l'autorità per modificarla affinché la cache diventi velenosa per tutti i successivi utilizzi del flusso di lavoro. Un singolo cache avvelenata potrebbe essere attivo per molto tempo, influenzando innumerevoli iterazioni di build di software eseguite in quella pipeline poiché la cache viene aggiornata solo quando c'è un nuovo artefatto o pacchetto da scaricare.
Proprio come nella verifica del file di istruzioni della pipeline, puoi utilizzare Valente per firmare e successivamente verificare la cache o una cartella contenente tutte le dipendenze pre-approvate richieste dalla pipeline. Se sei un tipo paranoico, consentire alla tua pipeline di connettersi in modo indipendente a Internet e scaricare tutte le librerie che ritiene necessarie è un modo sicuro per ottenere più vulnerabilità e possibili exploit nella build finale.
chiavi SSH – Una chiave SSH è una credenziale di accesso per il protocollo di rete SSH (secure shell). Questo protocollo di rete viene utilizzato per la comunicazione remota tra macchine su un rete aperta non protetta. SSH viene utilizzato per il trasferimento remoto di file, la gestione della rete e l'accesso remoto al sistema operativo. Con le chiavi SSH, ad esempio, puoi connetterti a GitHub senza fornire il tuo nome utente e il token di accesso personale ad ogni visita. Puoi anche utilizzare una chiave SSH per firmare i commit. Allo stesso modo puoi connettere altre applicazioni al tuo GitHub utilizzando chiavi SSH come BitBucket ed GitLab.
Per mantenere la sicurezza dell'account, dovresti rivedere regolarmente l'elenco delle chiavi SSH e revocare/eliminare eventuali chiavi non valide o compromesse. Per GitHub, puoi trovare l'elenco delle chiavi SSH nella pagina seguente:
accesso a impostazioni > Chiavi SSH e GPG
Uno strumento che può aiutarti a tenere sotto controllo le tue chiavi SSH è un rapporto sullo stato di sicurezza open source chiamato GitGat. Il report GitGat ti avviserà se una delle chiavi SSH configurate è scaduta o non è valida. Oltre a tenere d'occhio le tue chiavi e a ruotarle spesso, GitHub avverte che se vedi una chiave SSH con cui non hai familiarità, eliminala immediatamente e contatta Supporto GitHub per ulteriore aiuto. Una chiave pubblica non identificata può indicare una possibile violazione della sicurezza.
Provenienza SLSA come registro di pipeline immutabile - SLSA sta per Supply Chain Levels for Software Artifacts, un framework sviluppato da Google e altri partner del settore per contribuire a migliorare la sicurezza e l'integrità delle catene di fornitura del software.
SLSA definisce una serie di quattro livelli, ciascuno dei quali rappresenta un livello più elevato di fiducia e garanzia nella catena di fornitura del software. Ogni livello rappresenta un incremento crescente dei requisiti di sicurezza. Un requisito importante è la necessità di file di provenienza. Per il quadro SLSA,
La provenienza è l'informazione verificabile sugli artefatti software che descrive dove, quando e come è stato prodotto qualcosa. Poiché la maggior parte dello scopo di una pipeline CI/CD è produrre qualcosa (di solito una build), essere in grado di tracciare esattamente quali file sono stati inseriti e cosa è successo loro è una sorta di registro macchina non falsificabile della pipeline. A questo scopo è importante che la provenienza SLSA venga creata indipendentemente da qualsiasi utente. L'integrità di tutto ciò che un utente può interrompere o modificare può essere sospetta.
Uno strumento che ti consente di creare una provenienza SLSA nella tua pipeline per un'ampia varietà di sistemi SCM è Valente (sì, lo stesso strumento di Scribe: è uno strumento molto versatile). Il collegamento ti mostrerà come connettere Valint alla tua pipeline GitHub per generare una provenienza SLSA per ogni esecuzione di build su quella pipeline. Successivamente potrai accedere a ciascun file di provenienza e controllarlo per vedere se è successo qualcosa di spiacevole o inaspettato. Ecco uno snippet da un file di provenienza di questo tipo:
Il file di provenienza è solo un file JSON ma poiché non esistono (ancora) strumenti automatizzati per leggere i file di provenienza, il compito di leggerli e interpretarli spetta a te.
Garantire il risultato finale – Una delle violazioni della catena di fornitura del software più note degli ultimi tempi è la Incidente di SolarWinds. In esso, gli hacker hanno modificato parte del codice nel server di build in modo che ogni build rilasciata dall'azienda contenga una backdoor segreta. Un altro famoso caso di corruzione del risultato finale può essere visto nell’attacco dell’Autorità di certificazione del governo vietnamita (VGCA) nel 2020 soprannominato Operazione SignSight. Gli intrusi si sono infiltrati nel sito Web VGCA e hanno reindirizzato i collegamenti per il download alla propria versione del software, infettata da malware. In entrambi i casi, gli utenti finali non avevano modo di verificare che il software ricevuto fosse quello che l'azienda produttrice intendeva rilasciare.
Un attacco più semplice potrebbe essere quello di sostituire l'immagine finale creata alla fine della pipeline con un'immagine dannosa e caricare l'immagine dannosa ovunque debba andare. Poiché nella maggior parte degli attacchi di questo tipo l'immagine proviene presumibilmente dall'azienda produttrice, anche se tale azienda è protetta da un certificato valido non è sufficiente. Renderebbe il falso ancora più credibile.
Ancora una volta la soluzione è firmare crittograficamente qualunque sia l'artefatto finale prodotto dalla pipeline e consentire all'utente finale di verificare tale firma.
Dato che ho già detto Valente Suggerirò l'uso dell'open source Cosign di Sigstore. Cosign mira a semplificare la firma eliminando la necessità di infrastrutture chiave. Consente all'utente di utilizzare la propria identità verificata online (come Google, GitHub, Microsoft o AWS) come chiave. Puoi utilizzare Cosign sia per firmare che per verificare le immagini, rendendolo ideale per la firma e la successiva verifica dell'immagine finale creata di una pipeline.
Sia che tu scelga di utilizzare Valint o Cosign, consentire ai tuoi utenti di verificare una firma crittografica sul tuo artefatto finale per assicurarti che ottengano esattamente ciò che intendi fornire è un'idea che sono sicuro che la maggior parte degli utenti finali apprezzerebbe.
La sicurezza delle condutture nel futuro
Ci sono, ovviamente, altri elementi coinvolti in una pipeline di build che potrebbero trarre vantaggio da una maggiore sicurezza. In questo articolo, ho scelto di esaminare alcuni degli elementi della pipeline più ovvi e altri più vulnerabili.
Qualunque sia lo strumento o l'infrastruttura della pipeline che utilizzi, assicurati di tenere gli occhi aperti sulla possibilità di una violazione. Non fidarti mai ciecamente di un sistema che ti dice che è completamente sicuro.
Considerando la crescente minaccia di furto di identità, spear phishing e altre forme di falsificazione dell'accesso legittimo, riteniamo che il meccanismo di verifica della firma sia uno strumento utile e versatile da avere nella propria cassetta degli attrezzi digitale.
Se devi firmare un'immagine, un file o una cartella, ti invito a dare un'occhiata più da vicino a Valint di Scribe Security come strumento unico per tali esigenze.
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
