La pipeline che esegue la build e il deploy del tuo software ha più privilegi della maggior parte degli amministratori. Legge il codice sorgente, porta con sé le chiavi di firma e le credenziali cloud e scrive in produzione. Inoltre è assemblata con action, plugin e pacchetti di terzi che cambiano senza preavviso.
Testiamo questo percorso come farebbe un attaccante: che cosa può fare un contributore con diritti minimi, che cosa può raggiungere una dipendenza o una pull request malevola, e se è dimostrabile che l’artefatto messo in produzione è quello che è stato revisionato.
01Perimetro
Che cosa testiamo
Controllo del codice sorgente: protezione dei branch, regole di revisione, permessi, token di accesso
Definizioni delle pipeline: injection tramite input non attendibile, trigger non sicuri, workflow delle pull request
Runner: isolamento, stato che sopravvive tra un job e l’altro, raggiungibilità di rete, rischi dei runner self-hosted
Segreti: ambito, esposizione nei log, credenziali di lunga durata rispetto alla federazione di breve durata
Action, plugin e template di terzi: pinning e provenienza
Dipendenze: dependency confusion, typosquatting, file di lock, script di installazione
Artefatti e registri: firma, provenienza, controllo degli accessi
Deploy: separazione dei compiti, approvazioni, infrastructure as code
02Approccio
Come si svolge il lavoro
01
Mappatura
Tracciamo il percorso da un commit alla produzione ed elenchiamo i sistemi, le identità e i segreti che si trovano lungo di esso.
02
Revisione della configurazione
Repository, pipeline e registri vengono esaminati rispetto all’OWASP Top 10 CI/CD Security Risks e ai requisiti SLSA.
03
Simulazione di attacco
Dalle posizioni di un contributore esterno, di uno sviluppatore interno e di una dipendenza compromessa proviamo a raggiungere i segreti e ad alterare ciò che viene compilato. Il lavoro si svolge su fork e progetti di test ovunque questo basti a dimostrare il punto.
04
Piano di hardening
Le modifiche sono ordinate in base ai percorsi di attacco che chiudono. Ognuna è accompagnata dalla configurazione che la realizza.
Eseguiamo codice dimostrativo innocuo che mostra che cosa sarebbe raggiungibile, ad esempio il nome di un segreto e non il suo valore. Le pipeline di produzione vengono toccate solo dove le regole di ingaggio lo consentono; la maggior parte dei percorsi viene dimostrata in un progetto di test con la stessa configurazione.
Usiamo un servizio CI gestito. Della sicurezza non è responsabile il fornitore?
Il fornitore protegge la piattaforma. Ciò che ci metti sopra è tuo: permessi, trigger, segreti e componenti di terzi. È lì che gli attacchi alle pipeline hanno successo.
Il servizio include una distinta base del software (SBOM)?
Verifichiamo che la distinta base prodotta dalla tua build sia completa e corrisponda all’artefatto. Generarla e mantenerla fa parte della tua build; ti consigliamo come farlo.
Valutazione di ambienti AWS, Azure, Google Cloud e Kubernetes: identità, esposizione in rete, archivi di dati e percorsi da un punto d’appoggio al controllo completo.