No debería haber nada que cosechar

Ayer, una versión comprometida de la CLI de Bitwarden recopiló claves SSH, credenciales de AWS, tokens de npm, variables de entorno, el historial del shell y secretos de Git en 334 máquinas de desarrollo.

Hoy ha sido Bitwarden. El mes pasado, Axios. Antes, Checkmarx. Mañana será una extensión de VS Code, o Acrobat, o una fórmula de Homebrew, o una imagen de Docker. El vector cambia cada semana. El resultado es siempre el mismo.

El malware se instala. Lee ~/.ssh/. Lee ~/.aws/credentials. Lee ~/.npmrc. Lee ~/.git-credentials. Lee el historial del shell, las variables de entorno, los almacenes de contraseñas del navegador. Lo empaqueta todo y lo envía a un servidor C2.

Y funciona. Siempre.

La cosecha

La carga de Bitwarden — un archivo ofuscado de 10 MB llamado bw1.js — no intentó romper ningún cifrado. No lo necesitó. Esto es lo que recopiló, según lo documentado por Socket y Aikido:

• Claves SSH y huellas digitales de hosts
• Credenciales en la nube de AWS, GCP y Azure
• Tokens de autenticación de npm
• Credenciales de Git y URL de repositorios remotos
• Variables de entorno
• Historial del shell
• Autenticación de Claude Code y configuraciones de MCP

Después utilizó los tokens de npm robados para volver a publicar otros paquetes que mantenía la víctima, propagándose aún más. Las víctimas se convirtieron en vectores.

Nada de esto requirió romper el cifrado. Cada uno de estos secretos era un archivo en el sistema de ficheros, legible por cualquier proceso que se ejecutara como el usuario.

Esto no es una historia sobre Bitwarden

El cifrado de la bóveda de Bitwarden no se vio comprometido. Su arquitectura de conocimiento cero se mantuvo. El malware nunca tocó la bóveda.

No hacía falta.

La bóveda protege lo que hay dentro. Pero las claves SSH nunca estuvieron en la bóveda. Las credenciales de AWS nunca estuvieron en la bóveda. Los tokens de npm, las credenciales de Git, las claves de API en los archivos .env — nada de esto vive en los gestores de contraseñas. Viven en archivos dotfile, en texto plano, en la máquina de cada desarrollador.

El atacante lo entendió. La bóveda es una caja fuerte cerrada en una casa donde todos los cajones están abiertos.

La superficie de ataque real

Abra una terminal ahora mismo. Mire lo que hay en su máquina.

~/.ssh/id_ed25519 — su clave privada. Archivo en texto plano.

~/.aws/credentials — su acceso a la nube. Archivo en texto plano.

~/.npmrc — su token de publicación. Archivo en texto plano.

~/.git-credentials — su acceso al repositorio. Archivo en texto plano.

~/.env en una docena de directorios de proyectos — claves de API, contraseñas de bases de datos, secretos de firma. Todos archivos en texto plano.

Cualquier proceso que se ejecute como su usuario puede leer todo esto. No hace falta escalar privilegios. No hace falta ninguna vulnerabilidad. Solo cat.

Esta es la configuración por defecto del desarrollador en 2026. Guardamos nuestras contraseñas en una bóveda cifrada y dejamos todo lo demás al descubierto.

La pregunta equivocada

Tras cada ataque a la cadena de suministro, la industria se hace la misma pregunta: ¿cómo evitamos que el malware entre?

Mejor seguridad en CI/CD. Firmado de código. Análisis de dependencias. Entornos de ejecución aislados. Todo ello es bueno. Nada de ello es suficiente. La superficie de ataque es demasiado amplia. Hay demasiados vectores — gestores de paquetes, extensiones del navegador, complementos del IDE, aplicaciones OAuth, herramientas de compilación comprometidas. No se puede sellar cada punto de entrada.

La pregunta correcta es: cuando el malware obtenga ejecución de forma inevitable en la máquina de un desarrollador, ¿qué se encuentra?

Si la respuesta es «cientos de credenciales en texto plano en ubicaciones previsibles del sistema de ficheros», de nada sirve todo el endurecimiento de la cadena de suministro. Está jugando a la defensa en un campo donde la portería queda descubierta a sus espaldas.

No debería haber nada que cosechar

La solución no es una mejor detección de malware. La solución no es aislar npm install. La solución no es un tiempo de respuesta a incidentes más rápido.

La solución es: los secretos no deberían existir como archivos en el disco.

Claves SSH derivadas de hardware en el momento de la autenticación — no almacenadas en ~/.ssh/. Credenciales en la nube emitidas por sesión a partir de una identidad ligada al hardware — no escritas en ~/.aws/. Tokens de API con alcance limitado, efímeros y protegidos por hardware — no abandonados en archivos .env.

Cuando una credencial solo existe dentro de un módulo de seguridad de hardware y en la memoria efímera del proceso durante su uso, no hay nada que el malware pueda leer. Ningún archivo que extraer. Ningún archivo dotfile que rastrear. El proceso se ejecuta, no encuentra nada y sigue adelante.

Esto no es teórico. Las credenciales ligadas al hardware existen hoy. WebAuthn PRF puede derivar claves criptográficas a partir del contacto con un autenticador físico — claves que nunca tocan el sistema de ficheros. La tecnología está aquí. Lo que la industria no ha hecho es adoptarla como valor por defecto.

Qué hacer ahora

Si se ha visto afectado por el compromiso de la CLI de Bitwarden:

• Rote todas las credenciales de la máquina — claves SSH, tokens de la nube, tokens de npm, claves de API, todo lo que haya en archivos dotfile y variables de entorno
• Compruebe si alguno de los paquetes de npm que mantiene ha vuelto a publicarse
• Audite la actividad de GitHub y los flujos de trabajo de CI/CD en busca de cambios no autorizados

Si no se ha visto afectado, la acción es la misma. Observe su máquina. Cuente los secretos en texto plano. Pregúntese qué ocurre cuando — no si — algo malicioso se ejecute como su usuario.

La respuesta debería ser: nada. No debería haber nada que cosechar.