Non dovrebbe esserci nulla da raccogliere
Una versione compromessa della CLI di Bitwarden ha raccolto chiavi SSH, credenziali cloud e token npm da 334 macchine di sviluppo. Il vero problema non è come il malware sia entrato. È che ogni segreto era lì, sotto forma di file in chiaro, in attesa di essere letto.
Ieri, una versione compromessa della CLI di Bitwarden ha raccolto chiavi SSH, credenziali AWS, token npm, variabili d'ambiente, cronologia della shell e segreti Git da 334 macchine di sviluppo.
Oggi è stata Bitwarden. Il mese scorso Axios. Prima ancora, Checkmarx. Domani sarà un'estensione di VS Code, oppure Acrobat, oppure una formula Homebrew, oppure un'immagine Docker. Il vettore cambia ogni settimana. Il risultato è sempre lo stesso.
Il malware si installa. Legge ~/.ssh/. Legge ~/.aws/credentials. Legge ~/.npmrc. Legge ~/.git-credentials. Legge la cronologia della shell, le variabili d'ambiente, i contenitori di password del browser. Impacchetta tutto e lo invia a un server C2.
E funziona. Ogni volta.
La raccolta
Il payload di Bitwarden — un file offuscato da 10 MB chiamato bw1.js — non ha tentato di violare alcuna crittografia. Non ne aveva bisogno. Ecco cosa ha raccolto, come documentato da Socket e Aikido:
- Chiavi SSH e impronte degli host
- Credenziali cloud AWS, GCP e Azure
- Token di autenticazione npm
- Credenziali Git e URL remoti
- Variabili d'ambiente
- Cronologia della shell
- Autenticazione Claude Code e configurazioni MCP
Poi ha usato i token npm rubati per ripubblicare altri pacchetti mantenuti dalla vittima, diffondendosi ulteriormente. Le vittime sono diventate vettori.
Nulla di tutto questo ha richiesto di violare la crittografia. Ognuno di questi segreti era un file sul filesystem, leggibile da qualsiasi processo in esecuzione con i privilegi dell'utente.
Questa non è una storia su Bitwarden
La crittografia del vault di Bitwarden non è stata violata. La loro architettura a conoscenza zero ha retto. Il malware non ha mai toccato il vault.
Non ne aveva bisogno.
Il vault protegge ciò che contiene. Ma le chiavi SSH non sono mai state nel vault. Le credenziali AWS non sono mai state nel vault. Token npm, credenziali Git, chiavi API nei file .env — nulla di tutto questo vive nei gestori di password. Vive nei dotfile, in chiaro, sulla macchina di ogni sviluppatore.
L'attaccante lo sapeva. Il vault è un forziere chiuso in una casa in cui ogni cassetto è aperto.
La vera superficie di attacco
Apra un terminale adesso. Guardi cosa c'è sulla sua macchina.
~/.ssh/id_ed25519 — la sua chiave privata. File in chiaro.
~/.aws/credentials — il suo accesso al cloud. File in chiaro.
~/.npmrc — il suo token di pubblicazione. File in chiaro.
~/.git-credentials — il suo accesso ai repository. File in chiaro.
~/.env in una dozzina di directory di progetto — chiavi API, password di database, segreti di firma. Tutti file in chiaro.
Qualsiasi processo in esecuzione con i privilegi del suo utente può leggere tutto questo. Nessuna escalation di privilegi necessaria. Nessun exploit richiesto. Basta cat.
Questa è la configurazione predefinita di uno sviluppatore nel 2026. Mettiamo le nostre password in un vault cifrato e lasciamo tutto il resto allo scoperto.
La domanda sbagliata
Dopo ogni attacco alla supply chain, il settore si pone la stessa domanda: come impediamo al malware di entrare?
Sicurezza CI/CD migliore. Firma del codice. Analisi delle dipendenze. Runtime sandboxed. Sono tutte cose valide. Nessuna di esse è sufficiente. La superficie di attacco è troppo ampia. Ci sono troppi vettori — gestori di pacchetti, estensioni del browser, plugin per IDE, applicazioni OAuth, strumenti di build compromessi. Non è possibile sigillare ogni punto d'ingresso.
La domanda giusta è: quando il malware otterrà inevitabilmente l'esecuzione sulla macchina di uno sviluppatore, cosa troverà?
Se la risposta è «centinaia di credenziali in chiaro in posizioni prevedibili del filesystem», nessun irrobustimento della supply chain conta. Sta giocando in difesa su un campo in cui la porta è completamente scoperta alle sue spalle.
Non dovrebbe esserci nulla da raccogliere
La soluzione non è un rilevamento dei malware migliore. La soluzione non è mettere in sandbox npm install. La soluzione non è un tempo di risposta agli incidenti più rapido.
La soluzione è: i segreti non dovrebbero esistere come file su disco.
Chiavi SSH derivate dall'hardware al momento dell'autenticazione — non memorizzate in ~/.ssh/. Credenziali cloud emesse per sessione a partire da un'identità vincolata all'hardware — non scritte in ~/.aws/. Token API con ambito limitato, effimeri e vincolati all'hardware — non lasciati nei file .env.
Quando una credenziale esiste solo all'interno di un modulo di sicurezza hardware e nella memoria effimera del processo durante l'utilizzo, non c'è nulla che il malware possa leggere. Nessun file da esfiltrare. Nessun dotfile da raccogliere. Il processo si avvia, non trova nulla, prosegue.
Non è teoria. Le credenziali vincolate all'hardware esistono già oggi. WebAuthn PRF può derivare chiavi crittografiche da un tocco di un autenticatore fisico — chiavi che non toccano mai il filesystem. La tecnologia c'è. Il settore semplicemente non l'ha adottata come impostazione predefinita.
Cosa fare adesso
Se è stato interessato dalla compromissione della CLI di Bitwarden:
- Ruoti ogni credenziale sulla macchina — chiavi SSH, token cloud, token npm, chiavi API, tutto ciò che è nei dotfile e nelle variabili d'ambiente
- Verifichi se alcuni pacchetti npm da lei mantenuti sono stati ripubblicati
- Esamini l'attività GitHub e i workflow CI/CD alla ricerca di modifiche non autorizzate
Se non è stato interessato, l'azione è la stessa. Guardi la sua macchina. Conti i segreti in chiaro. Si chieda cosa succede quando — non se — qualcosa di malevolo si esegue con i privilegi del suo utente.
La risposta dovrebbe essere: nulla. Non dovrebbe esserci nulla da raccogliere.