Não Deve Haver Nada a Colher

Ontem, uma versão comprometida do CLI do Bitwarden recolheu chaves SSH, credenciais AWS, tokens npm, variáveis de ambiente, histórico de shell e segredos Git de 334 máquinas de programadores.

Hoje foi o Bitwarden. No mês passado foi o Axios. Antes disso, o Checkmarx. Amanhã será uma extensão do VS Code, ou o Acrobat, ou uma fórmula do Homebrew, ou uma imagem Docker. O vetor muda todas as semanas. O resultado é sempre o mesmo.

O malware chega. Lê ~/.ssh/. Lê ~/.aws/credentials. Lê ~/.npmrc. Lê ~/.git-credentials. Lê o histórico de shell, as variáveis de ambiente, as bases de palavras-passe do navegador. Empacota tudo e envia para um servidor C2.

E funciona. Todas as vezes.

A colheita

O payload do Bitwarden — um ficheiro ofuscado de 10 MB chamado bw1.js — não tentou quebrar nenhuma encriptação. Não precisava. Eis o que recolheu, conforme documentado pela Socket e pela Aikido:

• Chaves SSH e impressões digitais de hosts
• Credenciais de cloud AWS, GCP e Azure
• Tokens de autenticação npm
• Credenciais Git e URLs remotas
• Variáveis de ambiente
• Histórico de shell
• Autenticação do Claude Code e configurações MCP

Depois usou os tokens npm roubados para republicar outros pacotes mantidos pela vítima, espalhando-se ainda mais. As vítimas tornaram-se vetores.

Nada disto exigiu quebrar encriptação. Cada um destes segredos era um ficheiro no sistema de ficheiros, legível por qualquer processo a correr como o utilizador.

Isto não é uma história sobre o Bitwarden

A encriptação do cofre do Bitwarden não foi violada. A arquitetura de conhecimento zero manteve-se. O malware nunca tocou no cofre.

Não precisava.

O cofre protege o que está lá dentro. Mas as chaves SSH nunca estiveram no cofre. As credenciais AWS nunca estiveram no cofre. Tokens npm, credenciais Git, chaves de API em ficheiros .env — nada disto vive em gestores de palavras-passe. Vive em dotfiles, em texto claro, na máquina de cada programador.

O atacante percebeu isto. O cofre é um cofre trancado numa casa onde cada gaveta está aberta.

A superfície de ataque real

Abra um terminal agora. Veja o que está na sua máquina.

~/.ssh/id_ed25519 — a sua chave privada. Ficheiro em texto claro.

~/.aws/credentials — o seu acesso à cloud. Ficheiro em texto claro.

~/.npmrc — o seu token de publicação. Ficheiro em texto claro.

~/.git-credentials — o seu acesso aos repositórios. Ficheiro em texto claro.

~/.env numa dúzia de diretórios de projeto — chaves de API, palavras-passe de bases de dados, segredos de assinatura. Todos em texto claro.

Qualquer processo a correr como o seu utilizador pode ler tudo isto. Sem necessidade de escalamento de privilégios. Sem exploit. Basta cat.

Esta é a configuração predefinida de um programador em 2026. Ponemos as palavras-passe num cofre encriptado e deixamos todo o resto ao ar livre.

A pergunta errada

Depois de cada ataque à cadeia de abastecimento, a indústria faz a mesma pergunta: como impedimos o malware de entrar?

Melhor segurança de CI/CD. Assinatura de código. Análise de dependências. Tempos de execução isolados. Tudo isto é bom. Nada disto é suficiente. A superfície de ataque é demasiado ampla. Há demasiados vetores — gestores de pacotes, extensões de navegador, plugins de IDE, aplicações OAuth, ferramentas de build comprometidas. Não é possível selar todos os pontos de entrada.

A pergunta certa é: quando o malware obtiver execução, inevitavelmente, na máquina de um programador, o que é que encontra?

Se a resposta for "centenas de credenciais em texto claro em localizações previsíveis do sistema de ficheiros", nenhum reforço da cadeia de abastecimento importa. Está a jogar à defesa num campo onde a baliza está de portas abertas atrás de si.

Não deve haver nada a colher

A solução não é melhor deteção de malware. A solução não é isolar o npm install. A solução não é um tempo de resposta a incidentes mais rápido.

A solução é: os segredos não devem existir como ficheiros em disco.

Chaves SSH derivadas de hardware no momento da autenticação — não guardadas em ~/.ssh/. Credenciais de cloud emitidas por sessão a partir de uma identidade ligada a hardware — não escritas em ~/.aws/. Tokens de API com âmbito limitado, efémeros e protegidos por hardware — não parados em ficheiros .env.

Quando uma credencial só existe dentro de um módulo de segurança de hardware e em memória de processo efémera durante a utilização, não há nada para o malware ler. Sem ficheiro para exfiltrar. Sem dotfile para recolher. O processo corre, não encontra nada, segue.

Isto não é teórico. As credenciais ligadas a hardware existem hoje. O PRF do WebAuthn pode derivar chaves criptográficas a partir de um toque num autenticador físico — chaves que nunca tocam no sistema de ficheiros. A tecnologia está aqui. A indústria simplesmente não a adotou como predefinição.

O que fazer agora

Se foi afetado pela compromissão do CLI do Bitwarden:

• Rodar todas as credenciais na máquina — chaves SSH, tokens de cloud, tokens npm, chaves de API, tudo o que esteja em dotfiles e variáveis de ambiente
• Verificar se algum pacote npm que mantém foi republicado
• Auditar a atividade no GitHub e os fluxos de CI/CD por alterações não autorizadas

Se não foi afetado, a ação é a mesma. Olhe para a sua máquina. Conte os segredos em texto claro. Pergunte-se o que acontece quando — não se — algo malicioso correr como o seu utilizador.

A resposta deve ser: nada. Não deve haver nada a colher.