< Retour au Newsroom

LavaMoat arrive dans SSP — sandboxing runtime pour le multisig

·4 min de lecture·Par SSP Editorial Team
Badge de sécurité avec icônes de cadenas, bouclier coché, puce et éclair sur le titre « LavaMoat arrive dans SSP ».

Le 2025-10-23, SSP Wallet v1.27.0 a livré le changement de sécurité d'exécution le plus profond de l'année : LavaMoat, le framework de compartimentation JavaScript pionnier de MetaMask, est désormais intégré à SSP. Chaque dépendance tierce que le portefeuille charge est scellée dans son propre bac à sable, si bien qu'un paquet compromis — le risque de chaîne d'approvisionnement npm que tout portefeuille moderne affronte — ne peut plus lire ni modifier ce que font les autres parties du portefeuille. La release durcit aussi la Content Security Policy, cache une page de test de sécurité derrière un geste easter-egg, et apporte quelques victoires de polissage UI.

L'isolement à l'exécution arrive dans SSP

LavaMoat, en 30 secondes : un runtime qui prend l'arbre de dépendances d'une app JavaScript, isole chaque paquet dans son propre compartiment, et ne laisse chaque compartiment toucher que les globales et APIs que son fichier de politique lui accorde explicitement. Par défaut une dépendance tierce ne peut pas lire localStorage, ne peut pas appeler fetch, ne peut pas atteindre le trousseau, ne peut pas monkey-patcher Object.prototype. Si elle essaie, le runtime l'arrête.

C'est une posture différente de celle de la plupart des apps web, où chaque paquet importé s'exécute avec la même autorité que l'app elle-même. À l'intérieur de SSP, le code qui manipule les clés privées, l'intégration de swap qui parle aux APIs d'exchanges et les helpers UI tiers partageaient une seule portée globale. Depuis la v1.27.0, ce n'est plus le cas.

Pourquoi la compartimentation compte

La menace que la compartimentation est conçue pour neutraliser, c'est l'attaque par chaîne d'approvisionnement npm. Le schéma s'est répété en conditions réelles : un attaquant prend le contrôle d'un paquet populaire, publie une version malveillante, et chevauche la vague des dépendances transitives jusqu'à chaque app qui l'importe. Pour un portefeuille, l'impact d'un paquet malveillant s'exécutant avec l'autorité complète de l'app est catastrophique — il peut lire la seed en mémoire, exfiltrer des clés privées, ou réécrire des destinataires de transaction avant la signature.

LavaMoat n'empêche pas l'attaque d'atteindre l'app. Il supprime l'impact. Une dépendance compromise, même enterrée cinq niveaux profondément dans l'arbre, s'exécute dans un compartiment qui n'a pas accès à la surface de signature, pas d'accès réseau au-delà de ce que la politique autorise, et aucun moyen de lire l'état d'un autre compartiment. Paquet compromis ≠ portefeuille compromis — l'équivalence tient pour la première fois en v1.27.0.

Cela complète, plutôt que de remplacer, les protections livrées plus tôt dans l'année. Le code source de SSP a déjà été vérifié par l'audit complet Halborn, et le binaire que vous installez était déjà démontrable face à ce code grâce aux builds déterministes et à la signature GPG. LavaMoat ferme l'écart à l'exécution : même si une dépendance vire au malveillant après que le build est signé, elle ne peut pas escalader jusqu'à un accès au niveau du portefeuille.

Une Content Security Policy renforcée

Aux côtés de l'isolement à l'exécution, la v1.27.0 durcit aussi la Content Security Policy au niveau du navigateur. La CSP est le budget que le portefeuille se déclare à lui-même — depuis quelles origines il peut charger des scripts, avec quelles origines il peut parler, quels comportements inline sont permis. Une CSP plus stricte réduit l'espace dans lequel un attaquant peut opérer avant même que LavaMoat applique sa politique à l'intérieur de la page.

L'effet combiné, c'est deux couches de confinement : le navigateur refuse de charger les ressources hors politique déclarée, et tout JavaScript qui s'exécute est ensuite compartimenté par LavaMoat. Chaque couche couvre un mode de défaillance différent, et c'est précisément le principe de la défense en profondeur.

Une page de test de sécurité cachée

Pour la vérification interne — et c'est la seule fonctionnalité de la release livrée avec un easter egg délibéré — la v1.27.0 inclut une page de test de sécurité non exposée dans la navigation normale. Cliquer plusieurs fois rapidement sur le numéro de version la révèle. La page exécute une batterie de vérifications contre la politique LavaMoat et les règles CSP, pour que les relecteurs et les red-teamers puissent confirmer que les protections sont actives dans le build qu'ils inspectent sans avoir à instrumenter le portefeuille eux-mêmes. Elle n'est pas destinée aux utilisateurs au quotidien, et rien d'exploitable ne se cache derrière ; c'est simplement un moyen plus pratique de vérifier ce que v1.27.0 promet.

Défense en profondeur : audité + reproductible + isolé

L'intérêt de la v1.27.0 n'est pas LavaMoat isolé ; c'est la composition des trois pièces. Code source audité (Halborn), binaire reproductible que chacun peut vérifier contre cette source (builds déterministes), et un runtime qui contient toute dépendance compromise. Ensemble, ils transforment la question « est-ce que je fais confiance à l'arbre complet des dépendances de SSP ? » en « est-ce que je fais confiance au cœur audité ? » — une surface de confiance bien plus petite et bien plus traitable.

Le polissage UI vient par-dessus : les logos des exchanges du swap s'affichent désormais correctement et la palette de marque a été alignée sur l'ensemble des écrans. La compartimentation, c'est ce qui change la façon dont le portefeuille survit.

Partager cet article

Articles connexes