Il malware era firmato da Red Hat
Questa settimana del codice ruba-credenziali è arrivato agli sviluppatori portando il nome di Red Hat. La minaccia non è venuta dall'esterno del Suo cerchio di fiducia — ma dall'interno. Non può essere risolta con la verifica. Può però tenere le Sue credenziali fuori portata.
Questa settimana, del codice firmato da Red Hat ha tentato di rubare le Sue credenziali.
Gli attaccanti sono entrati nell'account di uno sviluppatore Red Hat e hanno pubblicato versioni manomesse dei pacchetti ufficiali Red Hat. Nell'istante in cui una macchina ne installava uno, del codice nascosto si eseguiva in automatico e metteva le mani su tutto ciò che trovasse di valore — chiavi cloud, token di accesso, credenziali, qualsiasi cosa che aprisse una porta. Poi usava ciò che aveva rubato per diffondersi.
Osservi la struttura di questo attacco. L'obiettivo non era Red Hat — era Lei. Il loro nome, il loro account affidabile, la pipeline di installazione che ha usato migliaia di volte senza pensarci: non sono stati la vittima collaterale. Sono stati l'arma. L'attacco non si è intrufolato oltre il Suo cerchio di fiducia. È entrato dalla porta principale indossando un badge che aveva emesso Lei stesso. È questo ciò che rende gli attacchi alla supply chain diversi da tutto il resto — il pericolo non è uno sconosciuto che può bloccare, ma il fornitore che ha già deciso di fiducia, che consegna il payload al Suo posto. E si trattava di Red Hat: una delle aziende più mature sul piano della sicurezza che esistano, con revisioni reali e budget reale. Il codice malevolo è comunque stato distribuito sotto il loro nome.
Ecco dunque la conclusione che non Le è concesso eludere: se Red Hat non può garantire che ciò che installa da loro sia pulito, nessuno può farlo. Non il Suo framework, non il Suo fornitore CI, non la dipendenza tre livelli più sotto che non ha mai letto. Prima o poi eseguirà del codice che non ha scritto e che non ha potuto verificare completamente. Non è un fallimento di processo — è ciò che significa costruire sul software di altri.
Continui a fare scanning. Continui a fissare le versioni. Continui a verificare. Vale la pena fare tutto questo — solo che non ci fidi sopra, perché questa settimana nulla di tutto ciò avrebbe aiutato: il malware è arrivato già attendibile. La vera domanda non è come tenere fuori il codice malevolo. È questa: quando del codice malevolo gira sulla Sua macchina, ha protetto i Suoi segreti?
Per quasi tutti, la risposta onesta è no. Guardi cosa ha preso questo attacco — variabili d'ambiente, token lasciati in file, e poi è andato ai secret manager del cloud a chiedere che gli consegnassero il loro contenuto. È così che vivono le credenziali nel 2026: ammucchiate in un unico posto, alla portata di chiunque stia girando in quel momento. Una brutta installazione non ruba un solo segreto. Li ruba tutti, poi si diffonde.
La soluzione è smettere di conservare le credenziali dove il Suo codice può afferrarle. Le tenga a debita distanza.
È questa l'idea alla base del funzionamento di Clavitor. I Suoi segreti non vivono nel Suo ambiente; niente aspetta in un file .env di essere letto. Un programma — o un agente AI — non detiene mai la credenziale. Ottiene la possibilità di usarne una, recuperata al momento del bisogno — mai archiviata, mai memorizzata nella cache — da una delle nostre 21 location su sei continenti, così la copia più vicina è sempre a pochi millisecondi di distanza, limitata al singolo segreto che gli è stato concesso, con ogni accesso registrato. Quando uno script di installazione malevolo brancola alla ricerca di chiavi, trova una stanza vuota.
E diamo per scontato che prima o poi una credenziale venga intercettata, quindi ciò che un agente porta con sé è quasi inutile se viene rubato. Funziona solo dalla macchina per cui è stato emesso — lo prelevi e lo usi dai server dell'attaccante stesso, e viene rifiutato. È soggetto a rate limiting e monitoraggio: pochi segreti al minuto, così non può aspirare l'intero vault, e nel momento in cui supera la sua normale manciata scatta un alert e il sistema si blocca. L'intera strategia di un worm — prendere tutto in fretta, usarlo ovunque — si scontra con un muro.
Nessuna promessa di immunità: se una credenziale è in uso attivo nell'istante in cui il malware gira, quella può essere intercettata — nessuna architettura riscrive la fisica. Ma è proprio questo il punto. L'attacco a Red Hat è stato devastante perché una sola installazione poteva svuotare un intero deposito di segreti e trasformarlo in arma. La distanza, più una credenziale legata a una singola macchina e limitata a un goccio, trasforma "hanno preso tutto e si sono diffusi" in "potrebbero aver intercettato una chiave in transito, e non ha funzionato da nessun'altra parte". È questa la distanza tra una catastrofe e una nota a piè di pagina.
Il malware era firmato da Red Hat. Non può batterlo in verifica. Dà per scontato che il codice entri — e si assicuri che, quando lo fa, i Suoi segreti non siano lì ad aspettarlo.
(Tracciato pubblicamente come "Miasma", una variante della famiglia di worm npm autodiffondenti Shai-Hulud. Le analisi tecniche meritano il Suo tempo; questo post riguarda la parte che non cambia da un caso all'altro.)
Fonti: