Perché la sicurezza della supply chain va nella Sua CI

1:53

La Sua build di produzione non è la build sul Suo laptop

La maggior parte dei team presume che il codice testato in locale sia il codice che viene distribuito. Il sorgente è lo stesso, ma il software spesso no. Una build è il codice sorgente più tutto ciò che scarica e tutto ciò che la circonda nel momento in cui viene eseguita, e ben poco di tutto questo è fisso.

Le dipendenze non fissate si risolvono in modo diverso

Gli intervalli di versione sono la norma. In npm, ^1.0.4 accetta qualsiasi release 1.x successiva, quindi lo stesso package.json installa versioni diverse in giorni diversi. Un lockfile le fissa, ma solo se è incluso nel repository e la build lo rispetta: npm ci fallisce quando lockfile e package.json non coincidono, mentre npm install può aggiornare il lockfile senza dire nulla. Molti progetti non lo includono affatto. Express 5.2.1, un framework web ampiamente usato, non lo fa.

Anche una versione fissata è un nome, non un file. La documentazione di pip spiega che il solo fissare la versione non impedisce a un indice di pacchetti di servire file diversi per la stessa versione, ed è per questo che offre la modalità di verifica degli hash.

Il tempo cambia gli input

I registry cambiano tra una build e l'altra. Vengono pubblicate nuove versioni, quelle vecchie vengono ritirate, e un intervallo che lunedì si risolveva in modo sicuro può prendere una release compromessa martedì. Anche i tag dei container si spostano: la stessa documentazione di Docker avverte che i tag delle immagini sono mutabili e che un publisher può aggiornare un tag perché punti a una nuova immagine, quindi FROM node:20 non è la stessa immagine base da un mese all'altro, a meno che non la fissi tramite digest.

Il tempo finisce anche dentro l'output. Il progetto Reproducible Builds indica i timestamp come la principale fonte di problemi di riproducibilità, perché moltissimi strumenti registrano la data e l'ora correnti in ciò che compilano.

L'ambiente è diverso

• Sistema operativo e architettura. Un laptop macOS con ARM e un runner CI Linux con x86-64 installano binari precompilati diversi per lo stesso pacchetto. Molti strumenti npm vengono ormai distribuiti come pacchetti specifici per piattaforma che incapsulano un binario compilato.
• Toolchain. Le versioni di compilatore, runtime e package manager divergono da una macchina all'altra, a meno che non siano tutte fissate.
• Cache. La Sua macchina e la Sua CI ripristinano cache diverse, create in momenti diversi da risoluzioni diverse.
• Script di installazione e passaggi di build. Hook di post-installazione, action di setup e script di build scaricano strumenti e dati in fase di build. Nulla di tutto questo compare in un manifest.
• Configurazione. Variabili d'ambiente, flag di build e secret esistono nella CI e da nessun'altra parte.

Il progetto Reproducible Builds definisce riproducibile una build in cui, a parità di codice sorgente, ambiente di build e istruzioni di build, chiunque può ricreare copie identiche bit per bit di tutti gli artefatti specificati. Questa definizione mostra quante cose devono restare costanti. Le build della maggior parte dei team non ci arrivano, e quelle che ci arrivano hanno richiesto un grande impegno. Finché non ci arriva, l'unico resoconto affidabile di ciò che è stato distribuito è quello registrato mentre era in esecuzione la build distribuita.

1:18

Dove si può controllare, e che cosa vede ciascun punto

I controlli di sicurezza possono essere eseguiti in quattro punti. Ciascuno ha il suo compito, ma solo uno vede la build che ha effettivamente prodotto la Sua release.

Una scansione del repository riporta ciò che il progetto dichiara. Una scansione dell'artefatto finito riporta ciò che riesce a riconoscere al suo interno. Nessuna delle due ha visto la build mentre avveniva. Express 5.2.1 non include alcun lockfile nel repository, quindi uno scanner puntato su un checkout pulito non ha nessuna delle dipendenze npm del progetto da risolvere e riporta tutto il resto che riconosce. Punti lo stesso strumento su una copia installata dello stesso repository e un flag dei cataloger cambia di nuovo la risposta. Il risultato dipende da ciò che era stato installato prima della scansione, ed è esattamente la parte che una scansione non controlla. La pagina sulle SBOM in fase di build spiega perché le scansioni divergono e che cosa cambia registrando la build.

La pipeline è un bersaglio a pieno titolo

La CI è il punto in cui si incontrano codice sorgente, dipendenze e secret, e questo la rende un obiettivo che vale la pena attaccare.

• tj-actions/changed-files (2025). Una GitHub Action ampiamente usata è stata compromessa e ha stampato i secret della CI nei log di build.
• Codecov Bash Uploader (2021). Uno script modificato, eseguito nella CI dei clienti, ha inviato le variabili d'ambiente al server di un attaccante.
• Il worm npm Shai-Hulud (2025). Pacchetti compromessi hanno rubato credenziali durante l'installazione e le hanno usate per pubblicare altri pacchetti compromessi.
• xz utils (2024). Una backdoor è stata nascosta negli archivi tar di release e nel processo di build stesso, non nel sorgente visibile.

Ciascuno di questi attacchi ha eseguito codice durante una build o un'installazione. Una scansione del repository eseguita prima, o una scansione dell'artefatto eseguita dopo, non avrebbe visto che cosa ha fatto il processo di build. I controlli che osservano e limitano ciò che un job può raggiungere devono trovarsi dove il job viene eseguito. Questo vale anche per le app interne e poco esposte: attacchi come questi puntano alla pipeline e ai pacchetti che tutte le app condividono, non a ciò che fa un'app. Veda la sicurezza della supply chain per il software interno e a basso rischio.

Più codice, più dipendenze, meno persone che le leggono

Gli agenti di coding basati sull'IA scrivono e modificano il codice più in fretta di quanto i team riescano a rivedere ogni riga, e nel farlo aggiungono dipendenze. Citano anche pacchetti che non esistono: uno studio presentato a USENIX Security 2025 su 576.000 campioni di codice generato ha rilevato tassi di pacchetti frutto di allucinazione almeno del 5,2% per i modelli commerciali e del 21,7% per i modelli open source. Se un attaccante registra uno di quei nomi, il suo pacchetto viene installato dalla prossima build che si fida di quel nome.

Ogni modifica, chiunque o qualunque cosa l'abbia scritta, passa attraverso la build per arrivare in produzione. Questo rende la build l'unico punto di controllo che non dipende dal fatto che qualcuno abbia guardato.

Le evidenze devono descrivere ciò che è stato distribuito

Normative e clienti chiedono prove, non intenzioni. Il Cyber Resilience Act dell'UE chiede ai fabbricanti di identificare e documentare i componenti dei loro prodotti e di gestirne le vulnerabilità per tutto il periodo di assistenza del prodotto. Una SBOM generata da un manifest descrive ciò che il progetto ha richiesto. Una SBOM registrata dalla build descrive ciò che è entrato nella release di cui Lei è responsabile. Quando viene pubblicata una nuova vulnerabilità, la seconda Le dice quali release sono colpite. Legga che cosa richiede il CRA.

Che cosa dovrebbe significare "nella CI"

Eseguire uno scanner come passaggio della CI è un inizio, ma lo scanner guarda comunque i file dopo il loro arrivo. Farlo correttamente nella CI significa:

1. Registrare, non dedurre. Acquisire ogni pacchetto e ogni file che il job scarica effettivamente, comprese le dipendenze transitive e tutto ciò che viene ripristinato da una cache.
2. Dichiarare quanto è completo il registro. Una SBOM dovrebbe indicare se copre tutto ciò che il job ha scaricato, non limitarsi a elencare ciò che ha trovato.
3. Controllare l'egress. Decidere quali host un job può raggiungere e bloccare il resto, prima che una dipendenza compromessa possa comunicare all'esterno.
4. Continuare a sorvegliare dopo il rilascio. Ricontrollare ciò che è stato distribuito man mano che emergono nuove vulnerabilità e trasformare i risultati in correzioni.

È ciò che fa CRACI. È un runner per i Suoi job GitHub Actions, quindi registra ciò che ogni build introduce, applica la policy di egress e monitora ciò che Lei ha distribuito. Spostare un workflow richiede una riga: runs-on: craci. Veda come funziona CRACI.

Che cosa la CI non sostituisce

Mettere la sicurezza della supply chain nella build non rende facoltativi gli altri livelli.

• Le macchine degli sviluppatori continuano a contenere credenziali e a eseguire script di installazione. Protegga anche quelle: un laptop compromesso può eseguire il push di codice prima di qualsiasi build.
• La code review e l'analisi statica trovano difetti nel Suo codice, cosa che un registro delle dipendenze non fa.
• Pinning, lockfile e digest restano buone pratiche. Riducono la distanza tra una build e l'altra; registrare la build Le dice comunque che cosa è successo.

La build non è l'unico punto in cui controllare. È l'unico punto che vede il software che Lei distribuisce davvero.