Best practice per la sicurezza della software supply chain

Sorgente

• Richieda un'autenticazione forte. Usi l'autenticazione a più fattori per ogni account di hosting del codice.
• Protegga il branch principale. Richieda una revisione prima del merge e non permetta a nessuno di fare push direttamente su un branch di release.
• Tenga i secret fuori dal codice. Li cerchi con una scansione a ogni push e ruoti tutto ciò che è stato esposto.
• Tratti i file di workflow come codice. Una modifica a una pipeline può raggiungere i Suoi secret, quindi ne richieda la revisione da parte dei responsabili.

Dipendenze

• Esegua il commit di un lockfile e installi da lì. Usi npm ci e i suoi equivalenti, così le build non acquisiscono nuove versioni per caso. Un lockfile ha dei limiti, ma è il punto da cui partire.
• Aggiunga un periodo di attesa per le nuove versioni. Le release malevole vengono spesso scoperte poco dopo la comparsa, quindi non adottare una versione il giorno stesso della pubblicazione dà tempo perché ciò accada.
• Limiti gli script di installazione. Li disattivi dove possibile. Gli script eseguiti durante l'installazione sono il mezzo con cui si diffondono i worm npm.
• Valuti le nuove dipendenze. Controlli che il nome non sia frutto di typosquatting e guardi manutenzione e popolarità. OpenSSF Scorecard ne automatizza una parte.
• Protegga i nomi dei pacchetti interni. Usi gli scope e la configurazione del registry, così un pacchetto pubblico non può prendere il posto di uno interno tramite dependency confusion.
• Elimini ciò che non serve. Ogni dipendenza è una cosa in più da monitorare.

Build e CI/CD

• Fissi le GitHub Actions a un hash di commit completo. I tag possono essere spostati, come ha dimostrato la compromissione di tj-actions.
• Limiti ciò che ogni job può fare. Assegni al token del workflow le autorizzazioni minime necessarie e usi credenziali di breve durata invece di secret di lunga durata.
• Limiti il traffico in uscita. Una build ha bisogno di pacchetti da sorgenti note e pubblica in luoghi noti. Blocchi tutto il resto, e i secret rubati non avranno dove andare. Veda policy di egress per GitHub Actions.
• Esegua ogni job in un ambiente nuovo e isolato. Nulla dovrebbe passare da un job al successivo, tanto meno da una pull request di un collaboratore esterno.
• Tratti le cache come un input. Una cache avvelenata sopravvive tra una build e l'altra, e ciò che ripristina passa facilmente inosservato. Veda cache di GitHub Actions.

Per l'elenco completo, veda la checklist di sicurezza per la pipeline CI/CD e il confronto sulla sicurezza dei runner.

Release

• Generi una SBOM per ogni release, dalla build. La conservi con l'artefatto. Veda le best practice per le SBOM.
• Firmi gli artefatti e pubblichi la provenance. Chi li utilizza potrà così verificare da dove proviene una release. SLSA ne definisce i livelli.
• Compili le release solo in CI. Dietro una release fatta da un portatile non c'è alcun registro affidabile.
• Usi un solo artefatto dal test alla produzione. Promuova ciò che ha testato, invece di ricompilarlo, così il registro resta veritiero.

Dopo il rilascio

• Monitori ciò che ha distribuito. Continui a confrontare le SBOM delle release supportate con le nuove vulnerabilità.
• Stabilisca le priorità non solo con il CVSS. Usi CISA KEV, EPSS e il contesto. Veda come dare priorità alle vulnerabilità.
• Sappia per quanto tempo è rimasto esposto. La cronologia delle build mostra quali release contenevano un pacchetto e da quando.
• Abbia un piano prima che serva. Decida chi fa il triage, chi corregge e chi parla con i clienti. Veda il ciclo di vita della gestione delle vulnerabilità.
• Si eserciti con uno scenario reale. Si chieda quanto tempo servirebbe per trovare ogni release con un determinato pacchetto. Se servono giorni, cominci da lì.

Da dove iniziare

Quando	Che cosa fare
Questa settimana	Autenticazione a più fattori, lockfile in CI, GitHub Actions fissate, token di workflow con privilegi minimi
Questo mese	SBOM da ogni build di release, avvisi sulle dipendenze con un responsabile, scansione dei secret
Questo trimestre	Regole per il traffico in uscita dalle build, monitoraggio delle release distribuite, un piano di risposta collaudato
In seguito	Provenance firmata, una revisione formale della copertura di SLSA o NIST SSDF, SBOM dei fornitori

Di quali pratiche si occupa CRACI

CRACI copre la build e tutto ciò che viene dopo. Come runner GitHub Actions, esegue ogni job nella propria macchina virtuale isolata, registra in una SBOM ogni pacchetto scaricato dal job, contrassegna i pacchetti ripristinati dalle cache CI e applica una policy di egress che blocca le connessioni di cui la Sua build non ha bisogno. Continua poi a controllare ciò che è stato distribuito, mostra quali build contenevano un pacchetto vulnerabile e può bloccare le build con i policy gate.

Il resto spetta ai Suoi altri strumenti: CRACI non scansiona codice sorgente né secret, non rileva nuovi pacchetti malevoli in base al comportamento e non firma SBOM né provenance. Veda gli strumenti per la sicurezza della software supply chain a confronto per sapere che cosa colma ogni lacuna.

Best practice per la sicurezza della software supply chain: domande frequenti

Come si protegge una software supply chain?

Sapendo che cosa si distribuisce grazie a una SBOM di ogni build di release, controllando che cosa entra con lockfile e valutazioni, proteggendo la build con limiti a secret e traffico in uscita, e continuando a monitorare ciò che si è rilasciato.

Che cosa dovrebbe fare per prima cosa un piccolo team?

Attivare l'autenticazione a più fattori, installare dai lockfile in CI, fissare le GitHub Actions agli hash di commit e assegnare ai token del workflow le autorizzazioni minime necessarie. Questi passaggi richiedono pochi giorni e chiudono percorsi di attacco comuni.

Come si prevengono i pacchetti malevoli?

Non basta un singolo passaggio. Ritardi l'adozione delle nuove versioni, limiti gli script di installazione e valuti le nuove dipendenze. Limitare il traffico in uscita dalle build riduce i danni se un pacchetto malevolo riesce a passare.

Perché fissare le GitHub Actions a un hash di commit?

Perché un tag di versione può essere spostato su un codice diverso. Un hash di commit completo fa sempre riferimento allo stesso codice, quindi un tag dirottato non raggiunge la Sua pipeline.

Con quale frequenza va rivista la supply chain?

Il monitoraggio deve essere continuo. Riveda la policy sulle dipendenze, le autorizzazioni dei workflow e il piano di risposta almeno una volta all'anno, e dopo ogni incidente nel Suo stack.