Checklist di sicurezza per pipeline CI/CD

Workflow

• Fissi le action di terze parti a un commit SHA completo. GitHub indica questa pratica come attualmente l'unico modo per usare un'action come release immutabile. Un tag può essere modificato per puntare ad altro codice. Nel marzo 2025 CISA ha segnalato che tutte le versioni di tj-actions/changed-files sono rimaste compromesse per tre giorni.
• Dia a GITHUB_TOKEN il privilegio minimo. Imposti come predefinita la sola lettura per i contenuti e conceda di più per singolo job.
• Non esegua mai il checkout di codice non attendibile in pull_request_target. Questi workflow vengono eseguiti con secret e permessi elevati.
• Tenga l'input non attendibile fuori dagli script. Passi titoli, nomi di branch e altri valori controllati dagli utenti tramite una variabile d'ambiente, invece di espanderli in un comando shell.
• Esamini le modifiche ai file di workflow. Richieda la revisione dei code owner per .github/workflows.

Secret

• Preferisca credenziali a breve durata. Usi OpenID Connect, così i job ottengono dal Suo cloud provider token a breve durata e con ambito limitato, invece di chiavi a lunga durata archiviate come secret.
• Limiti i secret agli ambienti. Metta le credenziali di produzione dietro un ambiente con revisori obbligatori.
• Esegua la rotazione dopo un incidente. Dopo la compromissione di tj-actions, CISA ha consigliato di trattare i secret esposti come compromessi e di ruotarli immediatamente.

Runner

• Usi runner effimeri. Una macchina nuova per ogni job non lascia nulla al job successivo.
• Tenga i runner self-hosted fuori dai repository pubblici. GitHub afferma che non dovrebbero quasi mai essere usati lì, perché chiunque può aprire una pull request sul repository.
• Isoli i job. Un job non dovrebbe poter leggere il workspace o le credenziali di un altro job.

Rete

• Controlli il traffico in uscita. Consenta le sorgenti dei pacchetti e i servizi di cui un job ha bisogno e blocchi il resto, così una dipendenza compromessa non può inviare secret all'esterno. Come una policy di egress ferma l'esfiltrazione
• Registri le connessioni. Conservi una traccia di ciò a cui ogni job si è connesso, così potrà indagare in seguito.

Dipendenze

• Esegua il commit dei lockfile. Le build dovrebbero risolvere ogni volta le stesse versioni.
• Esamini le nuove dipendenze. Controlli che cosa aggiunge una pull request prima del merge.
• Vincoli le build ai risultati. Blocchi una build quando introduce un pacchetto con una vulnerabilità critica nota, prima che l'artefatto venga distribuito.

Evidenze di build

• Registri una SBOM di ciò che la build ha scaricato. Una scansione dei file a posteriori descrive ciò che è stato dichiarato, non ciò che la build ha usato.
• Firmi la provenance. Colleghi ogni artefatto alla build che lo ha prodotto, così potrà verificare in seguito che ciò che viene eseguito è ciò che è stato compilato.
• Monitori ciò che è stato distribuito. Ricontrolli le build rilasciate quando vengono pubblicate nuove vulnerabilità.

Quali strumenti coprono quali voci

Gli scanner coprono le voci sulle dipendenze, gli strumenti di hardening delle pipeline coprono le voci sui workflow, e gli agent sul runner o un runner sicuro coprono le voci su rete ed evidenze. CRACI è il runner: applica una policy di egress in modalità fail closed, registra una SBOM di ciò che ogni job ha scaricato, consente ai policy gate di bloccare una build in base ai risultati e restituisce SBOM, tracce di rete e provenance tramite la sua API. Non scansiona codice né workflow. Veda gli strumenti di sicurezza CI/CD a confronto per sapere quale strumento copre che cosa.

Sicurezza delle pipeline CI/CD: domande frequenti

Che cos'è la sicurezza delle pipeline CI/CD?

È la protezione dei sistemi che compilano e distribuiscono il Suo software: le definizioni dei workflow, i secret che usano, i runner che li eseguono, le dipendenze che scaricano e gli artefatti che producono. Una pipeline compromessa può distribuire codice malevolo a Suo nome senza toccare il Suo codice sorgente.

Perché fissare le GitHub Actions a un commit SHA?

I tag possono essere modificati per puntare a codice diverso. GitHub afferma che fissare un'action a un commit SHA completo è attualmente l'unico modo per usarla come release immutabile. Nel marzo 2025 CISA ha segnalato che tutte le versioni di tj-actions/changed-files sono rimaste compromesse per tre giorni.

Quali permessi dovrebbe avere GITHUB_TOKEN?

Il minimo necessario a ciascun job. Imposti come predefinita la sola lettura per i contenuti del repository e conceda di più per singolo job, solo dove un job ne ha bisogno.

Mi serve il controllo del traffico di rete in uscita nella CI?

Se i Suoi job detengono secret ed eseguono codice di terze parti, sì. La maggior parte dei job deve raggiungere solo un insieme noto di registry di pacchetti e di servizi. Una policy di egress blocca tutto il resto, così una dipendenza compromessa non può inviare secret al server di un attaccante.