El 2025-10-23, SSP Wallet v1.27.0 aterrizó con el cambio de seguridad en tiempo de ejecución más profundo del año: LavaMoat, el framework de compartimentalización de JavaScript pionero de MetaMask, ya está integrado en SSP. Cada dependencia de terceros que carga la cartera queda sellada en su propio sandbox, de modo que un paquete comprometido — el riesgo de cadena de suministro npm que toda cartera moderna enfrenta — ya no puede leer ni alterar lo que hacen otras partes de la cartera. La release también endurece la Content Security Policy, esconde una página de pruebas de seguridad tras un gesto easter-egg, y trae unas cuantas mejoras de UI.
Llega el sandboxing en tiempo de ejecución a SSP
LavaMoat, en 30 segundos: un runtime que toma el árbol de dependencias de una app JavaScript, aísla cada paquete en su propio compartimento, y sólo deja que cada compartimento toque los globales y APIs que su archivo de política le concede explícitamente. Por defecto una dependencia de terceros no puede leer localStorage, no puede llamar a fetch, no puede tocar el keyring, no puede monkey-patchear Object.prototype. Si lo intenta, el runtime la frena.
Esa es una postura distinta a la de la mayoría de las apps web, donde cada paquete importado corre con la misma autoridad que la app misma. Dentro de SSP, el código que maneja claves privadas, la integración de swap que habla con APIs de exchanges y los helpers de UI de terceros solían compartir un único scope global. Desde v1.27.0, ya no.
Por qué la compartimentalización importa
La amenaza que la compartimentalización está diseñada para neutralizar es el ataque de cadena de suministro de npm. El patrón se ha visto en la realidad una y otra vez: un atacante toma el control de un paquete popular, publica una versión maliciosa y cabalga la ola de dependencias transitivas hasta cada app que lo importa. Para una cartera, el impacto de un paquete malicioso corriendo con autoridad completa es catastrófico — puede leer material de seed en memoria, exfiltrar claves privadas o reescribir destinos de transacciones antes de que el usuario firme.
LavaMoat no impide que el ataque llegue a la app. Elimina el impacto. Una dependencia comprometida, incluso una enterrada cinco niveles dentro del árbol, corre dentro de un compartimento que no tiene acceso a la superficie de firma, ni acceso de red más allá de lo que la política permite, ni forma de leer estado de otro compartimento. Paquete comprometido ≠ cartera comprometida — la equivalencia se sostiene por primera vez en v1.27.0.
Esto complementa, no reemplaza, las protecciones que aterrizaron antes este año. El código fuente de SSP ya fue verificado por la auditoría completa de Halborn, y el binario que instalas ya era demostrable contra ese código mediante builds deterministas y firma GPG. LavaMoat cierra el hueco del runtime: incluso si una dependencia se vuelve maliciosa después de firmar la build, no puede escalar a acceso a nivel de cartera.
Una Content Security Policy más fuerte
Junto al sandboxing en tiempo de ejecución, v1.27.0 también endurece la Content Security Policy en la capa del navegador. La CSP es el presupuesto que la cartera declara para sí misma — desde qué orígenes puede cargar scripts, con qué orígenes puede hablar, qué comportamientos inline están permitidos. Una CSP más estricta reduce el espacio en el que un atacante puede operar incluso antes de que LavaMoat aplique su política dentro de la página.
El efecto combinado son dos capas de contención: el navegador rehúsa cargar recursos fuera de la política declarada, y cualquier JavaScript que sí corre queda luego compartimentalizado por LavaMoat. Cada capa cubre un modo de fallo distinto, que es justamente el punto de defensa en profundidad.
Una página de pruebas de seguridad oculta
Para verificación interna — y esta es la única función de la release que viene con un easter egg deliberado — v1.27.0 incluye una página de pruebas de seguridad que no se expone en la navegación normal. Hacer clic varias veces seguidas sobre el número de versión la revela. La página corre una batería de comprobaciones contra la política de LavaMoat y las reglas de CSP, para que revisores y red-teamers puedan confirmar que las protecciones están activas en la build que inspeccionan sin instrumentar la cartera ellos mismos. No está pensada para usuarios cotidianos, y no hay nada explotable detrás de ella; es sólo una forma más cómoda de verificar lo que v1.27.0 promete.
Defensa en profundidad: auditado + reproducible + en sandbox
Lo interesante de v1.27.0 no es LavaMoat en aislamiento; es cómo se componen las tres piezas. Código fuente auditado (Halborn), binario reproducible que cualquiera puede verificar contra esa fuente (builds deterministas), y un runtime que contiene a cualquier dependencia comprometida. Juntas cambian la pregunta de «¿confío en todo el árbol de dependencias de SSP?» a «¿confío en el núcleo auditado?» — una superficie de confianza mucho menor y más respondible.
El pulido de UI llega encima: los logos de los exchanges del swap ahora se renderizan correctamente y la paleta de marca se ha alineado en todas las pantallas. La compartimentalización es lo que cambia cómo sobrevive la cartera.