TL;DR
Qualcuno ha finalmente fatto la prova ovvia: mettersi fra venticinque package manager e i registri di cui si fidano, cambiare i byte di un pacchetto legittimo e vedere chi se ne accorge. Se ne sono accorti due. Uno solo verifica le firme senza che glielo si chieda. Nel frattempo i controlli che il settore sta adottando davvero in questo autunno non sono crittografici, sono orologi: aspetta un giorno, aspetta una settimana, lascia scadere una configurazione non validata. Si chiama quarantena, data 1377, e ha due condizioni che il software sta rompendo.
La prova che nessuno fa sulla propria pipeline
Il 14 ottobre 2026 Trail of Bits ha pubblicato il risultato di un esperimento che sembra troppo noioso per contare. Si sono messi fra venticinque package manager diffusi e i registri da cui scaricano, hanno modificato un pacchetto legittimo in transito e hanno registrato quali installazioni fallivano.
Se ne sono accorti due: Go e vcpkg. Se si restringe alla verifica della firma con le impostazioni di default, resta uno. Go.
Gli altri hanno bisogno di un lockfile, di un flag, di un comando a parte o di una configurazione che nessuno scrive il venerdi pomeriggio. npm controlla l'hash del lockfile quando il lockfile c'e'. La firma del registro durante l'installazione no, quella e' un altro comando che ti devi ricordare. La loro conclusione e' la piu' onesta: la firma dei pacchetti sta piu' o meno dove stava HTTPS dieci anni fa.
Due su venticinque non e' un problema di adozione. E' un verdetto sull'approccio.
Cosa e' arrivato al posto dell'identita'
Guardiamo cosa il settore sta mettendo in produzione in queste settimane. pnpm ha un'impostazione che rifiuta qualsiasi versione pubblicata da meno di N minuti. .NET 11 RC2 ha aggiunto un flag che scrive un'eta' minima di pubblicazione nella configurazione NuGet. npm 12 ha reso gli script di installazione opt-in. E la correzione di GitHub al buco nel Trusted Publishing di npm, annunciata il 2 ottobre 2026, dice che le configurazioni non validate scadono dopo 48 ore.
Nessuno di questi controlli verifica niente. Aspettano.
Vale la deviazione, perche' quel buco spiega perche' l'identita' ha perso. Il Trusted Publishing era la risposta al furto dei token a lunga scadenza: la pipeline CI riceve una credenziale a vita breve. Solo che npm legava ogni configurazione allo slug del repository, proprietario e nome, invece che agli identificativi numerici permanenti che GitHub mette nel token di identita'. Rinomina il repository, trasferiscilo, cancella l'account proprietario, e il vecchio nome torna rivendicabile da chiunque abbia un workflow con il nome giusto.
Bloom Security lo ha segnalato il 6 giugno 2026. GitHub lo ha validato tre giorni dopo. L'ultima risposta e' arrivata l'8 luglio. Sei solleciti, compresa una richiesta di mediazione, senza risposta fino alla correzione del 2 ottobre: 118 giorni, piu' di 1.500 pacchetti esposti, oltre 10 milioni di download alle spalle. E un pacchetto pubblicato da quel buco portava con se' un attestato di provenienza valido, che certificava il repository dell'attaccante.
Ragusa, 1377
Nel 1377 Ragusa, oggi Dubrovnik, mette per legge un isolamento di trenta giorni per chi arriva dai porti infetti. Lo chiamano trentino. Altre citta' lo portano a quaranta giorni e ci lasciano la parola che usiamo ancora.
La quarantena non ha mai richiesto di sapere quale fosse il patogeno. Comprava il tempo perche' la malattia si dichiarasse, e funzionava.
E' esattamente quello che fa un'eta' minima di rilascio. Non ispeziona il pacchetto, non verifica chi lo pubblica, aspetta che un estraneo segnali il veleno. La finestra di rilevamento delle versioni npm malevole oggi sta fra una e ventiquattro ore dalla pubblicazione, quindi un giorno di attesa intercetta la gran parte degli attacchi opportunisti. Come misura di sicurezza e' poco spettacolare ed efficace, che per quello che vedo nelle pipeline reali e' la sola combinazione che sopravvive.
Perche' conta per la tua azienda
La quarantena ha due condizioni, e il software le sta rompendo entrambe.
La prima: qualcuno fuori deve guardare, perche' l'orologio compra tempo solo se un essere umano segnala il campione. Quel lavoro lo fanno manutentori non pagati e qualche gruppo di ricerca dei fornitori, ed e' la voce che non entra mai in un budget di sicurezza.
La seconda: l'orologio deve essere piu' lento dell'attacco. Bruce Schneier, il 10 settembre 2026, ha messo il problema in una riga: dai a un agente la semplice voce di un exploit e gli basta per trovarlo.
Poi c'e' la questione di chi installa i pacchetti adesso. La telemetria di Bloom stima intorno a settanta pacchetti al mese installati dagli agenti su un endpoint tipico e circa trecentocinquanta su una macchina da sviluppo, dipendenze escluse. Un agente che deve attendere una settimana prima di usare una dipendenza non e' un agente. E' un ticket.
Quindi la domanda da portare in consiglio non e' se il tuo SBOM e' pulito. E': qual e' la tua eta' minima di rilascio, su chi stai contando perche' se ne accorga per primo, e cosa fanno i tuoi agenti mentre aspettano?