I dettagli di ciò che accade all’interno delle pipeline CI/CD sono notoriamente opachi. Nonostante abbia scritto il file di configurazione YAML, che è l'elenco delle istruzioni della pipeline, come puoi essere certo che tutto avvenga esattamente come descritto? Ancora peggio, la maggior parte delle condutture sono del tutto transitorie, quindi, anche in caso di malfunzionamento, ci sono poche prove oltre a quelle registrate che potrebbero includere o meno i dettagli del problema.
Lo sviluppo rapido è ottenuto attraverso l'uso di pipeline automatizzate di integrazione continua/distribuzione continua (CI/CD). Avere trigger o pianificazione che compilano, costruiscono, testano e spediscono automaticamente il tuo codice è fantastico. La maggior parte delle condutture, tuttavia, non sono costruite pensando alla sicurezza, essendo state progettate per velocità e comodità d'uso. Poiché le pipeline in genere richiedono l'accesso a Internet per scaricare dipendenze e file, una volta compromessa una pipeline, l'aggressore ha una varietà di opzioni per interrompere l'operazione o esfiltrare informazioni o segreti.
In questo articolo tratterò alcune delle best practice che puoi mettere in atto per proteggere la tua pipeline CI/CD. Per i nostri scopi, non importa quali strumenti o sistemi di automazione utilizzi: i principi di sicurezza rimangono validi. Devi solo trovare lo strumento giusto per proteggere quella sezione della tua pipeline.
Che cos'è la pipeline CI/CD (integrazione continua/consegna continua)?
Una pipeline CI/CD è un processo automatizzato per creare, testare e pubblicare software, applicazione o artefatto. Queste condutture stanno diventando sempre più comuni e complesse. Le pipeline sono uno strumento eccellente per aumentare la produttività del team e produrre artefatti software in modo più coerente e prevedibile. L’importanza dell’automazione di queste procedure diventa molto più evidente se si tiene conto del fatto che le aziende più grandi possono avere centinaia di pipeline interconnesse e coreografate, che dipendono tutte l’una dall’altra per funzionare bene.
La creazione e il test automatici e regolari delle modifiche al codice in un nuovo prodotto finale sono noti come integrazione continua o CI. Le modifiche alla codifica vengono fornite, testate e integrate come parte di un processo in due fasi denominato distribuzione e/o distribuzione continua (CD). La distribuzione continua distribuisce automaticamente gli aggiornamenti nell'ambiente di produzione, mentre la distribuzione continua si interrompe subito prima della distribuzione automatica di produzione. Il fatto che la tua pipeline utilizzi l'uno o l'altro dipende completamente da te e dal modo in cui sono impostati i tuoi ambienti e i tuoi risultati finali.
L'importanza della sicurezza CI/CD per la catena di fornitura del software
La maggior parte delle aziende fa affidamento su Strumenti CI / CD per automatizzare le loro condutture. Ciò significa che, come molti altri attacchi alla catena di fornitura del software, tutto ciò di cui i malintenzionati hanno bisogno è violare un singolo bersaglio per ottenere un vasto raggio di esplosione. Uno dei principali punti deboli è la necessità che la pipeline scarichi e integri le dipendenze nel prodotto o artefatto finale. Anche una cattiva dipendenza è sufficiente per dare un punto d'appoggio a un elemento indesiderato nella pipeline. Poiché la pipeline ha accesso al codice sorgente e a vari altri elementi della tua infrastruttura (secondo necessità), un'escalation di privilegi può accedere e successivamente modificare o estrarre quasi ogni parte del prodotto creato in quella particolare pipeline.
Un semplice esempio può essere trovato nella nostra spiegazione di a avvelenamento da cache o dipendenze.
Negli ultimi anni, diverse grandi aziende hanno subito attacchi alla catena di fornitura di software che avevano come punto di origine una pipeline CI/CD. Ad esempio, puoi guardare La violazione di CircleCI nel gennaio del 2023, Il compromesso di Argo CD nel gennaio del 2022, e il Violazione del Codecove nel mese di aprile 2021.
Le potenziali conseguenze di tali attacchi sono gravi, quindi ha senso fare tutto il possibile per assicurarsi che le proprie condutture siano quanto più sicure possibile.
Best practice per la sicurezza CI/CD
Qualunque sia la piattaforma o gli strumenti CI/CD che stai utilizzando, ci sono alcune cose che puoi fare per rafforzare la tua sicurezza e ridurre il potenziale danno nell'improbabile caso in cui un attore ostile riesca ad accedere alla tua pipeline o rete.
Monitoraggio e avvisi – Potrebbe verificarsi una violazione anche se i tuoi ingegneri sono stati addestrati a prestare attenzione al phishing e ad altre frodi di ingegneria sociale. Poiché la maggior parte degli ambienti pipeline sono temporanei, una volta terminato il lavoro, non rimarranno molte tracce a meno che non vengano registrate attivamente. Mentre lavori su ogni PR, unione, creazione e test, assicurati che tutte le modifiche apportate all'ambiente o ai file di configurazione vengano registrate. I dati dell'utente dovrebbero anche essere registrati insieme a tutti gli altri dati per essere esaminati se un problema lo richiede. Essere in grado di ricostruire una violazione e determinare cosa è andato storto e come è andato storto è lo scopo qui. Seleziona in anticipo gli eventi che dovrebbero attivare un avviso e assicurati che le parti interessate siano informate. Fare attenzione a non sopraffare le persone con avvisi inutili o eccessivamente sensibili; ciò potrebbe portare ad un affaticamento da allerta, che li indurrebbe semplicemente a ignorare gli avvisi o a reagire molto più tardi di quanto sia prudente.
Utilizzare il principio RBAC combinato con il privilegio minimo – Fornire l'accesso alle risorse di sistema in base al ruolo designato dall'utente o alla funzione lavorativa all'interno di un'organizzazione è la base del controllo degli accessi basato sui ruoli o RBAC. Agli utenti vengono assegnati ruoli in RBAC che specificano i loro diritti di accesso e autorizzazioni a diverse risorse di sistema, come file, cartelle e programmi. D'altra parte, il concetto di privilegio minimo si riferisce alla pratica di fornire agli utenti la quantità minima di accesso e privilegi necessari per svolgere le proprie mansioni lavorative. Ciò implica che gli utenti si limitino a utilizzare le risorse necessarie per completare i lavori assegnati e niente di più. Il privilegio minimo e l'RBAC vengono spesso applicati insieme come concetti di sicurezza complementari. Il principio del privilegio minimo garantisce che gli utenti abbiano accesso solo alla quantità minima di risorse necessarie per svolgere i loro compiti particolari e RBAC assegna ruoli che forniscono agli utenti la giusta quantità di accesso alle risorse di cui hanno bisogno per svolgere le loro funzioni lavorative e niente di più . Se combinate, queste linee guida aiutano a mantenere un sistema ben mantenuto e relativamente sicuro. Puoi configurarlo per richiedere più autorizzazioni utente per azioni essenziali del sistema come ulteriore livello di sicurezza. Questa strategia dovrebbe essere utilizzata con attenzione poiché potrebbe causare un notevole ritardo nel processo di sviluppo.
Mantieni la provenienza della pipeline come registro immutabile – Le informazioni verificabili sugli artefatti software che descrivono dove, quando e come è stato creato qualcosa sono note come provenienza. Sapere esattamente quali file sono stati inseriti e cosa è successo loro in una pipeline può essere generato come file di provenienza per formare un registro non falsificabile di quella pipeline. Per essere sicura, la provenienza deve essere creata indipendentemente da qualsiasi utente, poiché tutto ciò che un utente può interrompere o modificare non è del tutto affidabile. Valint dello scriba Consente di stabilire la provenienza nella vostra pipeline per un'ampia gamma di sistemi SCM. Ogni file di provenienza (JSON) è accessibile in seguito, quindi puoi esaminarlo per determinare se si è verificato qualcosa di imprevisto o indesiderato. A proposito, la generazione e la gestione dei file di provenienza da tutte le pipeline è il cuore del Struttura SLSA.
Utilizza appieno la tua SBOM – Nel caso in cui ti fossi perso alcuni dei potenziali usi, una SBOM creata alla fine della pipeline potrebbe aiutare a elencare tutti i pacchetti open source utilizzati. Il confronto di tale elenco con i CVE noti potrebbe dirti quali potenziali vulnerabilità esistono nel tuo prodotto finale. Puoi anche utilizzare l'elenco per verificare se stai ancora utilizzando versioni obsolete di pacchetti open source e persino utilizzare qualcosa come Scheda punteggi OpenSSF per verificare la "salute" dei pacchetti che stai utilizzando. Poiché nuovi CVE vengono costantemente alla luce, dovresti avere un servizio, a differenza di un SAST una tantum, che ti consente di sapere se in uno dei tuoi pacchetti esistenti è stato scoperto un nuovo CVE. Il servizio di Scribe può aiutarti a fare tutto questo automaticamente.
Verifica la conformità alle tue policy – Ogni azienda, e talvolta ogni oleodotto, ha politiche che devono essere attuate per garantire che tutto vada bene. Alcune politiche sono generiche (come assicurarsi che ci sia un processo di verifica da parte di due persone), mentre altre sono uniche (come assicurarsi che Mike approvi l'ultima modifica prima di inviarla alla produzione). Utilizzando il meccanismo di verifica del segno crittografico e un file di policy univoco, ora puoi includere le policy necessarie in ciascuna pipeline e verificare (a te stesso e agli altri) che abbiano avuto luogo. È una debolezza umana che, se stressata, può far sì che alcuni requisiti vengano ignorati e alcune regole piegate per rispettare una scadenza. Con questa misura in atto, le persone non possono più infrangere le regole e ciò dovrebbe aiutare a mantenere la sicurezza della pipeline da minacce sia interne che esterne. Scribe ha sviluppato un nuovo modo per applicare tali politiche e persino consentirti di scriverne di tue. Controlla qui.
Proteggi il file di istruzioni della pipeline – Gli autori delle minacce possono “avvelenare” la pipeline CI utilizzando una tecnica nota come esecuzione avvelenata della pipeline (PPE), che sostanzialmente modifica le fasi della pipeline o la loro sequenza come originariamente specificato nel file di istruzioni della pipeline. Il metodo manipola il processo di compilazione abusando delle autorizzazioni nei repository di gestione del codice sorgente (SCM). Inserendo codice o comandi dannosi nelle impostazioni della pipeline di compilazione, è possibile avvelenare la pipeline e causare l'esecuzione di codice dannoso mentre la compilazione viene completata. Non sarai in grado di dire che le tue build non funzionano come previsto fino a quando o a meno che non controlli il file di istruzioni della pipeline. Per essere sicuro che le pipeline vengano eseguite come previsto, è necessario verificare il file di istruzioni prima di ogni esecuzione. Dal punto di vista crittografico, firmare il file e aggiungere la verifica della firma come primo passo della pipeline è un modo per ottenere tale sicurezza. Valint dello scriba firmare e verificare Le funzioni sono un modo per verificare che il file di istruzioni sia rimasto inalterato prima di avviare qualsiasi nuova esecuzione della pipeline.
Assicurati il tuo risultato finale – Perché un utente malintenzionato dovrebbe impegnarsi a fondo per interrompere la tua pipeline quando sostituire il prodotto finale con una versione fraudolenta è molto più semplice? Dato che in questi tipi di attacchi la società generatrice sembra essere la fonte dell'immagine, non è sufficiente che tale società disponga di un certificato valido che la protegga. Detto semplicemente, aumenterebbe la credibilità del falso. La soluzione è firmare crittograficamente qualunque sia l'artefatto finale prodotto dalla pipeline e consentire all'utente finale di verificare tale firma. Il Valint dello Scriba può essere usato firmare e verificare una grande varietà di artefatti che ti danno quella sicurezza extra che i tuoi utenti otterranno esattamente ciò che volevi che ottenessero.
Guardando al futuro
Nessuno smetterà di utilizzare tecniche di automazione come CI/CD per accelerare il proprio lavoro. Al contrario, nel mondo in cui viviamo, spingiamo sempre per iterazioni di aggiornamento software sempre più veloci. Dovremmo, per lo meno, assicurarci di affrontare il compito con cautela, facendo attenzione a non mettere a repentaglio il nostro ambiente di produzione o il nostro codice sorgente nel processo.
La cosa cruciale è considerare le potenziali conseguenze di qualcuno che ottiene un accesso illegale alla tua pipeline, al tuo ambiente o al tuo codice sorgente. Sono sicuro che sarai in grado di intraprendere le azioni appropriate per fermare o mitigare potenziali perdite una volta che ti renderai conto di quanto potrebbe essere pericoloso e dove le tue condutture e la tua rete sono più sensibili.
Poiché la complessità delle pipeline interconnesse è destinata ad aumentare, è fondamentale mantenere la sicurezza complessiva dell'ambiente (rete segmentata, RBAC, zero trust e così via) come primo passo per proteggere le pipeline. Successivamente, cerca di creare prove solide e non falsificabili e utilizza la firma crittografica e la verifica dei dati per cercare di mitigare il più possibile il potenziale di un attacco alla catena di fornitura del software che potrebbe avvelenare la tua pipeline o la cache della pipeline. Rimanere vigili e sospettosi potrebbe risparmiare indicibili mal di testa alla tua azienda.
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
