Sicurezza CI/CD

Perché le pipeline sono un bersaglio

• Custodiscono le chiavi. Credenziali cloud, token dei registry e chiavi di firma passano tutti dalla CI.
• Eseguono il codice di altri. Ogni dipendenza, script di installazione e action di terze parti viene eseguito sul runner.
• Raggiungono la produzione. Tutto ciò che esce dalla pipeline viene considerato attendibile, firmato e distribuito. Un attaccante nella build raggiunge tutti i clienti in una volta sola.
• Pochi le sorvegliano. I file di workflow cambiano di rado e ricevono meno revisioni del codice applicativo.

La compromissione di tj-actions e il worm npm Shai-Hulud hanno entrambi preso di mira i secret in CI. Veda che cos'è un attacco alla supply chain per capire come si svolgono questi attacchi.

I principali rischi per la sicurezza CI/CD

La OWASP Top 10 CI/CD Security Risks è il riferimento standard. Raggruppati in base a ciò che va storto:

Area	Rischi OWASP	Come si presenta
Chi può modificare che cosa	Controllo del flusso insufficiente, gestione di identità e accessi inadeguata	Il codice arriva in produzione senza revisione, oppure i vecchi account conservano i loro accessi
Che cosa viene eseguito nella pipeline	Abuso della catena delle dipendenze, poisoned pipeline execution	Un pacchetto malevolo o un workflow modificato viene eseguito con gli accessi del job
Che cosa può raggiungere un job	Controlli di accesso basati sulla pipeline insufficienti, igiene delle credenziali insufficiente	Un job può leggere tutti i secret e i token restano validi per anni
Come è configurato	Configurazione di sistema non sicura, uso non governato di servizi di terze parti	Runner senza patch e integrazioni con più accessi del necessario
Che cosa può dimostrare	Convalida impropria dell'integrità degli artefatti, logging e visibilità insufficienti	Nessuno sa dire che cosa è entrato in una release o a che cosa si è connesso un job

Per ogni rischio associato ai controlli dei runner, veda la sicurezza dei runner a confronto.

Best practice per la sicurezza CI/CD

1. Tratti le definizioni delle pipeline come codice di produzione. Richieda la revisione dei file di workflow e tenga le pull request non attendibili lontane dai secret.
2. Limiti ciò che ogni job può fare. Dia ai token solo i permessi minimi necessari e preferisca le credenziali di breve durata ai secret archiviati.
3. Fissi le action di terze parti a un hash di commit. I tag possono essere spostati su altro codice.
4. Isoli i job. Esegua ogni job in un ambiente nuovo, così che nulla passi al successivo.
5. Controlli il traffico in uscita. Una build ha bisogno di fonti note e destinazioni note. Bloccare tutto il resto impedisce ai secret rubati di uscire. Veda policy di egress per GitHub Actions.
6. Registri ciò che è successo. Conservi una SBOM di ogni build e un log della sua attività di rete, così da poter rispondere alle domande in seguito.

Per la versione passo dopo passo, veda la checklist di sicurezza per la pipeline CI/CD.

Tipi di strumenti per la sicurezza CI/CD

Tipo	Che cosa fa	Esempi
Sicurezza dei runner	Isola i job e controlla ciò che possono raggiungere durante l'esecuzione	CRACI, StepSecurity
Gestione della postura	Individua impostazioni rischiose di pipeline e repository	Legit Security, Cycode, Apiiro, OX Security
Scansione di codice e dipendenze	Controlla codice, dipendenze e secret a ogni modifica	GitHub Advanced Security, Snyk, Semgrep
SBOM ed evidenze	Registra ciò che è entrato in ogni release	CRACI, Syft, Anchore

Questi strumenti agiscono in fasi diverse, quindi la maggior parte dei team li combina. Uno scanner esamina i file prima della build, gli strumenti di postura esaminano le impostazioni e la sicurezza dei runner agisce mentre il job è in esecuzione, cioè nel momento in cui agisce un pacchetto malevolo. Veda gli strumenti per la sicurezza della software supply chain a confronto e gli strumenti DevSecOps a confronto.

Dove si colloca CRACI

CRACI protegge la build mentre è in esecuzione. Sostituisce i Suoi runner ospitati da GitHub con runner più veloci e meno costosi: ogni job viene eseguito nella propria macchina virtuale isolata, una policy di egress blocca le connessioni di cui la build non ha bisogno e ogni pacchetto scaricato dal job finisce in una SBOM. Poiché la policy consente solo ciò che serve alla build, La protegge anche da un attacco che nessuno ha mai visto prima.

CRACI non controlla la configurazione dei Suoi workflow, non scansiona codice sorgente o secret e non firma la provenance, quindi per queste attività mantenga o aggiunga altri strumenti. GitHub Actions è il sistema CI supportato oggi, e altri sistemi CI sono in roadmap.

Sicurezza CI/CD: domande frequenti

Che cos'è la sicurezza CI/CD?

È la pratica di proteggere le pipeline che creano, testano e distribuiscono il software, comprese le loro credenziali, il codice che eseguono e gli artefatti che producono.

Quali sono i maggiori rischi per la sicurezza CI/CD?

Dipendenze malevole e action di terze parti, pipeline compromesse, token con troppi permessi e secret di lunga durata, e la mancanza di visibilità su ciò che ha fatto una build. La OWASP Top 10 CI/CD Security Risks è l'elenco standard.

Che cos'è la poisoned pipeline execution?

Un attaccante modifica ciò che una pipeline esegue, per esempio cambiando tramite una pull request un file di workflow o uno script che richiama, così che il suo codice venga eseguito con gli accessi della pipeline.

Come si protegge una pipeline CI/CD?

Rivedendo le modifiche alla pipeline, dando a ogni job solo gli accessi minimi necessari, fissando le action di terze parti a un hash di commit, isolando i job, limitando il traffico in uscita e conservando un registro di ciò che ha fatto ogni build.

Qual è la differenza tra sicurezza CI/CD e DevSecOps?

DevSecOps è la pratica più ampia di integrare la sicurezza nel modo in cui si sviluppa il software. La sicurezza CI/CD si concentra sulla pipeline stessa, da cui dipendono anche gli strumenti DevSecOps.

GitHub Actions ha bisogno di ulteriore sicurezza?

GitHub offre controlli come i permessi dei token e la scansione dei secret, ma deve configurarli Lei, e i runner ospitati non limitano il traffico in uscita per impostazione predefinita. La maggior parte dei team aggiunge pinning, regole di revisione e controlli sui runner.