Minacce alla supply chain

Un attacco alla catena di approvvigionamento del software compromette un'organizzazione non violandola direttamente, ma corrompendo qualcosa di cui essa si fida e che utilizza: una libreria, uno strumento di build, un'immagine di base di un container o un server di aggiornamento.

Poiché il software moderno viene assemblato a partire da centinaia di componenti di terze parti, un singolo elemento avvelenato viene ereditato da ogni utilizzatore a valle. L'attaccante investe una sola volta e raggiunge molte vittime.

• Inversione della fiducia — il perimetro di sicurezza si sposta al di fuori del Suo codice
• Raggio d'impatto transitivo — un pacchetto compromesso si propaga in migliaia di build

Quando aggiunge una dipendenza diretta, spesso introduce decine di dipendenze transitive che non ha mai scelto. Una tipica applicazione Node o Python dichiara una manciata di pacchetti, ma ne risolve centinaia.

Elencare l'intero albero risolto, non solo il manifest, per vedere cosa distribuisce effettivamente:

Gli attaccanti pubblicano pacchetti dannosi con nomi simili a quelli più diffusi, contando su un errore di battitura fatale.

• Typosquatting — reqeusts al posto di requests
• Combosquatting — python-requests che imita il nome reale
• Dependency confusion — pubblicazione di un pacchetto pubblico con lo stesso nome di quello privato interno, così un resolver configurato erroneamente scarica la versione dell'attaccante

Si difenda configurando un registry interno affidabile e utilizzando pacchetti privati con scope o namespace.

Un pacchetto legittimo e ampiamente considerato affidabile può diventare ostile se l'account del maintainer viene compromesso o se un collaboratore malevolo ottiene i diritti di pubblicazione.

Recenti incidenti reali mostrano che gli attaccanti sottraggono con il phishing le credenziali dei maintainer, quindi pubblicano una release correttiva avvelenata che esfiltra token durante l'installazione.

• Richieda la 2FA per tutti gli account che pubblicano pacchetti
• Preferisca pacchetti con token di pubblicazione associati a uno scope e release protette
• Controlli la presenza di nuovi maintainer inattesi nelle dipendenze critiche

Molti ecosistemi eseguono codice durante l'installazione, prima ancora che l'applicazione venga avviata. Un npm install può eseguire un hook postinstall che sottrae variabili d'ambiente o chiavi SSH.

Disabiliti gli script di installazione arbitrari nella CI e sottoponga a verifica qualsiasi pacchetto che ne abbia bisogno:

L'ambiente di build è di per sé un obiettivo di grande valore. Se un attaccante avvelena un compilatore, l'immagine di un runner CI o un plugin di build, ogni artefatto prodotto contiene una backdoor, anche quando il codice sorgente è integro.

Un esempio classico è un meccanismo di aggiornamento trojanizzato che firma il malware con una chiave legittima di firma del codice, inducendo le vittime ad accettarlo come autentico.

• Tratti l'infrastruttura di build come un ambiente di produzione, applicando un hardening completo
• Utilizzi runner di build effimeri e riproducibili
• Tenga separate le chiavi di firma dall'host di build

Un lockfile fissa versioni esatte e hash del contenuto, impedendo a una nuova risoluzione di sostituire silenziosamente un artefatto con uno diverso. Lo inserisca sempre nel repository e faccia in modo che la CI lo verifichi, invece di risolvere nuovamente le dipendenze senza vincoli.

Il campo di integrità contiene un hash; se il tarball scaricato non corrisponde, l'installazione non va a buon fine.

Le versioni note per essere vulnerabili (tracciate come CVE) sono la debolezza più comune della catena di approvvigionamento. Gli strumenti di Software Composition Analysis (SCA) confrontano le dipendenze risolte con i database delle vulnerabilità.

Esegua le scansioni nella CI e interrompa le build in presenza di risultati critici:

Gli intervalli di versione mobili (^1.2.0) consentono alle nuove release di entrare automaticamente, una soluzione comoda che però La espone a una patch malevola.

• Fissi le versioni esatte e valuti deliberatamente gli aggiornamenti
• Fissi tramite digest le immagini dei container, anziché tramite tag mutabili come latest
• Includa le dipendenze critiche nel Suo repository o mirror, così l'eliminazione da parte del progetto a monte non potrà interrompere o compromettere il Suo sistema

La sicurezza della catena di approvvigionamento è un'attività continua, non una scansione una tantum. Deve sapere cosa distribuisce, da dove proviene e quando diventa vulnerabile.

• Generi un SBOM per ogni release (nella prossima lezione)
• Acquisisca la provenienza della build, così da poter dimostrare come è stato prodotto un artefatto
• Si abboni agli avvisi, in modo che una nuova CVE renda necessaria una rivalutazione delle build già distribuite

Mappi ogni fase in cui entra un input non affidabile: le macchine degli sviluppatori, il controllo del codice sorgente, i registry delle dipendenze, il sistema di build, l'archiviazione degli artefatti e il canale di aggiornamento. Ognuna è un potenziale punto di inserimento.

Per ogni fase si chieda: chi può scrivere qui, cosa potrebbe fare in caso di compromissione e come lo rileverei? In questo modo otterrà un elenco prioritizzato di controlli, anziché una checklist generica.

Ha appreso perché le dipendenze sono vettori d'attacco e come ridurre questa esposizione.

• L'inversione della fiducia significa che la sicurezza dipende da terze parti che non controlla
• Le minacce principali sono: typosquatting, dependency confusion, acquisizione del controllo sul maintainer, script di installazione malevoli e strumenti di build compromessi
• Le difese fondamentali sono: lockfile con hash di integrità, scansione SCA, fissaggio esatto tramite digest, 2FA per gli account che pubblicano pacchetti e monitoraggio continuo

Successivamente inventarierà esattamente il contenuto del Suo software con un SBOM.