Che cos'è la sicurezza della software supply chain?

Che cos'è la software supply chain?

La software supply chain è l'insieme di persone e strumenti che portano il software dall'editor di uno sviluppatore alla produzione. La si può immaginare in quattro fasi, ciascuna con i propri rischi.

Fase	Che cosa comprende	Che cosa può andare storto
Sorgente	Il Suo codice, i repository e gli account degli sviluppatori	Credenziali rubate, commit malevoli, secret esposti
Dipendenze	Pacchetti open source, immagini base, codice di terze parti	Versioni vulnerabili, release malevole, typosquatting
Build	Runner CI, GitHub Actions, strumenti di build, cache	Action compromesse, cache avvelenate, secret della pipeline rubati
Release	Artefatti, registry, deployment, aggiornamenti	Artefatti sostituiti, aggiornamenti manomessi, nessun registro di ciò che è stato distribuito

Perché conta adesso

Gran parte di ciò che Lei distribuisce non l'ha scritto Lei. Un'applicazione moderna è in gran parte open source, e ogni dipendenza diretta ne porta con sé altre che nessuno nel Suo team ha scelto. Quei pacchetti vengono eseguiti con gli stessi accessi del Suo codice, e i loro script di installazione possono essere eseguiti all'interno della Sua pipeline CI, accanto ai Suoi secret.

La storia degli ultimi anni mostra come tutto questo viene sfruttato:

• SolarWinds: la build è stata compromessa, quindi da un sorgente pulito è nata una release avvelenata.
• Log4Shell: un difetto in una libreria di logging ha raggiunto prodotti che non sapevano di usarla.
• xz utils: un collaboratore fidato ha inserito una backdoor in un progetto presente nelle distribuzioni Linux.
• tj-actions: una GitHub Action dirottata ha eseguito codice dell'attaccante nelle pipeline che la usavano, con i secret a portata di mano.
• Shai-Hulud: un worm si è diffuso attraverso i pacchetti npm, rubando token dalle macchine e dai job CI che li installavano.

Per capire passo dopo passo come funzionano questi attacchi, veda che cos'è un attacco alla supply chain.

Come funziona la sicurezza della software supply chain

Un programma ha bisogno di quattro cose. Tutto il resto è dettaglio.

1. Sapere che cosa distribuisce. Conservi una SBOM accurata per ogni release, generata dalla build che l'ha prodotta, comprese le dipendenze transitive.
2. Controllare che cosa entra. Fissi le versioni, usi un lockfile, limiti le fonti da cui le build possono scaricare e valuti i nuovi pacchetti.
3. Proteggere la build. Isoli i job, limiti i secret, fissi le action a un commit e limiti il traffico in uscita, così un pacchetto compromesso non può inviare i Suoi token da nessuna parte. Veda la sicurezza dei runner e perché la sicurezza della supply chain va nella CI.
4. Continuare a sorvegliare ciò che è stato distribuito. Le nuove vulnerabilità colpiscono software già in produzione. Lo monitori, individui quali release sono colpite e segua ogni correzione fino a una nuova release.

Per la checklist dettagliata, veda le best practice per la sicurezza della software supply chain.

Framework e normative

Nome	Che cos'è	Ideale per
SLSA	Livelli per l'integrità della build e la provenance	Rafforzare il modo in cui il software viene compilato
NIST SSDF	Pratiche di sviluppo sicuro, SP 800-218	Un programma completo di sviluppo sicuro
NIST SP 800-161	Gestione del rischio informatico nella supply chain	Gestione del rischio a livello di organizzazione
OpenSSF Scorecard	Controlli automatici sullo stato di salute dei progetti open source	Valutare le dipendenze
Cyber Resilience Act	Legge dell'UE per i prodotti con elementi digitali	Vendere nell'UE. Veda che cos'è il CRA

Quali strumenti sono coinvolti?

Nessun singolo prodotto copre tutto questo. La categoria si divide in strumenti SCA, strumenti SBOM, sicurezza di CI/CD e runner, firewall per pacchetti, application security posture management e analisi dei binari. Per sapere che cosa fa ciascuno e chi lo vende, veda gli strumenti per la sicurezza della software supply chain a confronto e quanto costano.

Da dove iniziare

1. Generi una SBOM per il Suo prodotto più importante a partire dalla sua build CI, e la legga.
2. Attivi gli avvisi di vulnerabilità sulle dipendenze e decida chi ne è responsabile.
3. Fissi le Sue GitHub Actions a un commit e controlli i secret a cui i Suoi workflow possono accedere.
4. Limiti il traffico in uscita dalle Sue build agli host di cui hanno effettivamente bisogno.
5. Imposti il monitoraggio di ciò che ha distribuito, non solo di ciò che sta compilando.

L'approccio di CRACI

CRACI parte dalla build, perché la build è l'unico punto che vede tutto. Sostituisce i Suoi runner ospitati da GitHub con runner più veloci e meno costosi che registrano ogni pacchetto scaricato da ciascun job, a ogni profondità dell'albero e compresi i pacchetti ripristinati dalle cache CI. La policy di egress blocca le connessioni di cui la Sua build non ha bisogno, quindi La protegge anche da un attacco che nessuno ha mai visto. CRACI continua poi a confrontare ciò che è stato distribuito con le nuove vulnerabilità e segue ciascuna dal triage fino a una release corretta. Veda la sicurezza della software supply chain con CRACI.

Sicurezza della software supply chain: domande frequenti

Che cos'è la sicurezza della software supply chain?

È la pratica di proteggere tutto ciò che entra nel Suo software prima che raggiunga gli utenti: dipendenze open source, sistemi di build, strumenti della pipeline e release.

Qual è un esempio di attacco alla software supply chain?

Nell'attacco a SolarWinds la build è stata compromessa, quindi i clienti hanno ricevuto un aggiornamento avvelenato da un vendor fidato. Negli attacchi Shai-Hulud un worm si è diffuso attraverso i pacchetti npm e ha rubato token dalle macchine che li installavano.

Qual è la differenza tra sicurezza della supply chain e sicurezza applicativa?

La sicurezza applicativa esamina i difetti nel codice che Lei scrive. La sicurezza della supply chain esamina ciò che Lei non ha scritto e il modo in cui il Suo software viene compilato e rilasciato. Un programma ha bisogno di entrambe.

Basta una SBOM per la sicurezza della supply chain?

No. Una SBOM Le dice che cosa distribuisce, e questa è la base. Serve anche controllare che cosa entra, proteggere la build e continuare a monitorare ciò che ha rilasciato.

Quali sono i principali framework?

SLSA per l'integrità della build, il NIST SSDF per le pratiche di sviluppo sicuro e NIST SP 800-161 per la gestione del rischio della supply chain. Nell'UE, il Cyber Resilience Act stabilisce requisiti di legge per i prodotti con elementi digitali.

Chi è responsabile della sicurezza della software supply chain?

Di solito l'application security o la product security, in collaborazione con i team di piattaforma e DevOps che gestiscono le pipeline. Le correzioni passano poi ai team di engineering responsabili di ciascun servizio.