La mayoría de los consejos de seguridad para usuarios cripto se centran en las superficies que puedes ver: tu frase semilla, los enlaces que tocas, los sitios donde inicias sesión. Eso importa. Pero hay un riesgo más silencioso debajo de todos ellos: el propio software y todo aquello con lo que fue construido. Una billetera puede estar escrita a la perfección y aun así distribuir una puerta trasera, porque las aplicaciones modernas se ensamblan a partir de cientos de bloques de terceros y de un proceso de compilación que convierte el código fuente en el binario que instalas. Compromete cualquier eslabón de esa cadena y comprometerás a todos los usuarios que vienen después.
Esto es la cadena de suministro de software, y los atacantes han aprendido que es uno de los objetivos de mayor apalancamiento en cripto. Este artículo explica qué es realmente un ataque a la cadena de suministro, por qué las billeteras son blancos tan atractivos, las defensas que funcionan en la práctica y qué te aportan las compilaciones deterministas, incluyendo cómo aplica todo esto SSP.
Qué es un ataque a la cadena de suministro
Un ataque a la cadena de suministro no irrumpe directamente en la aplicación. En cambio, compromete algo en lo que la aplicación confía: una dependencia que incorpora, la cuenta de un mantenedor o el proceso de compilación que ensambla el artefacto final. El código malicioso entra a través de una actualización legítima, firmada y entregada por los canales normales, de modo que se ve exactamente como el software que querías instalar.
Esa indirección es justamente el objetivo. Atacar una biblioteca muy usada —o un servidor de compilación— puede alcanzar a miles de proyectos derivados y a millones de usuarios a la vez. Para una billetera cripto la recompensa es directa: el código que corre dentro de tu billetera ya tiene acceso al momento que importa, cuando se firma una transacción y se muestran las direcciones. Una sola dependencia manipulada puede cambiar una dirección de destino o exfiltrar material de claves sin tocarte jamás mediante phishing o una débil higiene de la frase semilla. Por eso esta clase de ataque merece un lugar en tu modelo mental.
Dos casos que tocan de cerca
Dos incidentes reales muestran cómo se desarrolla esto: uno apuntado de lleno a cripto, otro que casi golpea a todo internet.
event-stream y la billetera Copay
En 2018, un popular paquete de npm llamado event-stream fue cedido a un nuevo mantenedor voluntario que se ofreció a ayudar. Fue un traspaso rutinario y de apariencia bienintencionada, del tipo que ocurre constantemente en el código abierto. El nuevo mantenedor añadió entonces una dependencia nueva, flatmap-stream, que contenía código malicioso ofuscado.
La carga útil era inusualmente dirigida. En lugar de activarse para todos, solo lo hacía dentro de un proyecto derivado específico: la billetera Copay de Bitcoin. Allí estaba diseñada para robar material de la semilla y fondos de los usuarios de esa aplicación. La mayoría de los desarrolladores que incorporaron event-stream nunca se vieron afectados: el código sabía exactamente a qué víctima buscaba.
Es el recordatorio canónico de que "solo instalé una pequeña biblioteca" nunca es la historia completa. También instalaste todo aquello en lo que esa biblioteca confía.
La puerta trasera de XZ Utils
El incidente de XZ Utils de 2024 (CVE-2024-3094) fue aún más paciente. XZ Utils es una biblioteca de compresión presente discretamente en la mayoría de los sistemas Linux. A lo largo de años, un atacante fue ganando confianza como colaborador servicial, asumió poco a poco responsabilidades de mantenimiento y luego introdujo una puerta trasera diseñada para interferir con OpenSSH, el software que protege los inicios de sesión remotos en servidores de todo el mundo.
Se descubrió casi por accidente, gracias a un ingeniero que notó un retraso de una fracción de segundo. De haberse distribuido ampliamente, podría haber entregado acceso remoto a innumerables máquinas.
La lección para cripto es aleccionadora: el ataque no explotó un error ingenioso, explotó el propio modelo de confianza del código abierto, jugando una partida de ingeniería social de varios años para convertirse en la persona de la que todos dependían.
Las defensas que de verdad funcionan
Ningún control aislado detiene los ataques a la cadena de suministro. Lo que funciona es una pila de ellos, cada uno reduciendo las opciones del atacante:
- Dependencias fijadas y archivos de bloqueo. Fijar versiones exactas y registrar un archivo de bloqueo significa que una compilación no puede traer en silencio una versión más nueva y manipulada. Las actualizaciones se vuelven eventos deliberados y revisables, no automáticos.
- Dependencias mínimas. Cada paquete que añades es una parte en la que confías. Menos dependencias significa una superficie de ataque más pequeña y menos mantenedores que podrían verse comprometidos.
- Aislamiento de dependencias. Herramientas como LavaMoat limitan lo que cada paquete puede hacer en tiempo de ejecución, de modo que una dependencia comprometida no pueda alcanzar libremente la red ni APIs sensibles.
- Firma de código. Las versiones firmadas permiten a los usuarios verificar que un binario proviene del publicador real y no fue alterado en tránsito.
- Auditorías de terceros. Empresas de seguridad independientes revisan el código y las dependencias con ojo adversario, detectando lo que los equipos internos normalizan.
- Compilaciones reproducibles y deterministas. La defensa estructural más fuerte, y la que vale la pena entender en detalle.
Compilaciones deterministas, explicadas
Normalmente, compilar el mismo código fuente dos veces puede producir dos binarios ligeramente distintos: se filtran marcas de tiempo, orden de archivos y detalles de la máquina de compilación. Esa variabilidad es un problema, porque significa que no puedes distinguir una diferencia benigna de una maliciosa.
Una compilación determinista (o reproducible) elimina esa variabilidad. Dado el mismo código fuente, cualquiera, en cualquier lugar y en cualquier máquina, produce un artefacto idéntico byte a byte. La implicación es poderosa: personas independientes pueden recompilar la billetera a partir de su código fuente público y confirmar que el binario que descargaste coincide, bit a bit, con lo que produce el código fuente. Si un atacante manipuló el proceso de compilación o introdujo algo después, los hashes no coincidirán y la manipulación se vuelve visible de inmediato.
Esto invierte el modelo de confianza. Ya no tienes que creer en la palabra del publicador; la verificación se convierte en algo que toda la comunidad puede realizar y contrastar. El proyecto Reproducible Builds documenta esta práctica en todo el ecosistema, y marcos como SLSA definen niveles de garantías de integridad de compilación que puedes exigir a un proyecto.
Cómo lo aplica SSP
SSP trata el proceso de compilación como parte de su modelo de amenazas, no como una ocurrencia tardía. La billetera se distribuye con una compilación determinista basada en Dockerfile: el mismo entorno definido por Docker produce el mismo artefacto cada vez, de modo que una versión publicada puede recompilarse a partir del código fuente público y compararse, bit a bit, con lo que descargaste. SSP también se ha sometido a revisiones de seguridad independientes por parte de Halborn, cuyas auditorías examinan tanto el código como las dependencias en las que se apoya.
Hay una capa más, específica de cómo está construido SSP, y aquí importa. SSP es una billetera multisig 2 de 2: cada transacción requiere una aprobación independiente de una segunda clave, la SSP Key, en un dispositivo separado. Conviene ser preciso sobre lo que esto hace y lo que no. Las compilaciones deterministas y las auditorías reducen la probabilidad de que una compilación manipulada llegue a distribuirse; son la primera línea. Pero incluso en el peor caso —una compilación que de algún modo se cuele— la segunda clave es una superficie de aprobación separada que aún tiene que firmar cada transacción.
No es un escudo mágico, ni hace aceptable una compilación comprometida. Simplemente significa que un único componente manipulado en un dispositivo no mueve tus fondos por sí solo. La defensa en profundidad es la idea.
Qué puedes comprobar tú mismo
No necesitas ser ingeniero de seguridad para beneficiarte de todo esto. Unos pocos hábitos rinden mucho:
- Descarga solo de fuentes oficiales. Consigue la billetera desde su sitio oficial o su ficha de tienda, nunca desde un enlace en un mensaje o un anuncio de búsqueda. Es la misma disciplina que cubre la higiene de extensiones del navegador.
- Prefiere proyectos que publiquen compilaciones deterministas y auditorías. Un proyecto que permite a la comunidad verificar sus versiones —y paga una revisión independiente— te dice algo sobre cómo piensa.
- Verifica firmas y hashes cuando se ofrezcan. Si una versión incluye una firma o suma de verificación, dedica el minuto a comprobarla. Las compilaciones reproducibles solo te protegen si alguien hace de verdad la comparación.
- Mantén tu opsec general firme. Las defensas de la cadena de suministro forman parte de un panorama mayor; repasa tu lista de opsec con regularidad para que ninguna capa cargue con todo el peso.
Nada de esto exige confiar en una sola parte. Esa es exactamente la propiedad que quieres del software de autocustodia.
Sigue adelante
Una billetera es tan confiable como la cadena que la construyó. La buena noticia es que este es uno de los pocos problemas de seguridad con una respuesta limpia y estructural: las compilaciones deterministas más las auditorías independientes convierten el "confía en nosotros" en "verifícalo tú mismo".
Sigue construyendo tus defensas con conciencia del phishing, buenas prácticas de la frase semilla, higiene de extensiones del navegador y una lista de opsec periódica. Cada una cierra una puerta; juntas son lo que de verdad parece la seguridad en autocustodia.
