Supply chain del software: l’anello debole sono le dipendenze

Il software moderno non si scrive: si assembla. Un’applicazione media trascina con sé centinaia di dipendenze dirette e migliaia di transitive, scritte da sconosciuti, aggiornate a ritmi che nessuna revisione umana può seguire. Gli attaccanti l’hanno capito prima dei difensori: compromettere un pacchetto a monte significa entrare in tutte le build che lo usano, e la storia recente è una collezione di casi che hanno funzionato esattamente così.

I punti deboli ricorrenti sono tre. Il manutentore: account rubati, progetti abbandonati ceduti a volontari mai verificati, pressioni sociali costruite ad arte. La distribuzione: registry pubblici dove pubblicare è facile e impersonare un nome lo è quasi altrettanto, tra typosquatting e versioni avvelenate. E la build: pipeline con permessi larghi e segreti in chiaro, dove un singolo passo compromesso firma artefatti che tutti tratteranno come buoni.

La risposta non è smettere di usare l’open source — senza, semplicemente non si produce software — ma trattare la catena come si tratta il perimetro: con inventario, verifica e minimo privilegio.

Il pacchetto minimo realistico: una distinta dei componenti (SBOM) generata a ogni build, il blocco delle versioni con aggiornamenti deliberati e non automatici, la firma degli artefatti e la verifica delle firme altrui, e pipeline con credenziali effimere che non possono pubblicare nulla fuori dal loro recinto. Nessuna di queste misure è esotica; la differenza la fa applicarle insieme, e sempre.

Resta la parte difficile: le dipendenze transitive che nessuno ha scelto consapevolmente. Lì aiutano gli strumenti di analisi, ma aiuta di più una domanda da fare a ogni nuova libreria: chi la mantiene, da quanto, e cosa succede a noi il giorno in cui smette? La sicurezza della catena comincia dalla qualità delle scelte, non dagli scanner.