Am 2025-10-23 landete SSP Wallet v1.27.0 mit der tiefgreifendsten Laufzeit-Sicherheitsänderung des Jahres: LavaMoat, das von MetaMask wegbereitende JavaScript-Compartmentalization-Framework, ist jetzt in SSP integriert. Jede Drittabhängigkeit, die das Wallet lädt, ist in einer eigenen Sandbox versiegelt, sodass ein kompromittiertes Paket — das npm-Lieferketten-Risiko, dem jedes moderne Wallet ausgesetzt ist — nicht länger lesen oder verändern kann, was andere Teile des Wallets tun. Die Release verschärft außerdem die Content Security Policy, versteckt eine kleine Sicherheits-Testseite hinter einer Easter-Egg-Geste und bringt eine Handvoll UI-Politur-Gewinne obendrauf.
Laufzeit-Sandboxing kommt in SSP an
LavaMoat in 30 Sekunden: ein Runtime, das den Abhängigkeitsbaum einer JavaScript-App nimmt, jedes Paket in ein eigenes Kompartment isoliert, und jedem Kompartment nur Zugriff auf die Globals und APIs erlaubt, die ihm in einer Policy-Datei explizit gewährt wurden. Standardmäßig kann eine Drittabhängigkeit weder localStorage lesen noch fetch aufrufen, nicht in den Keyring greifen, nicht Object.prototype monkey-patchen. Versucht sie es, stoppt das Runtime sie.
Das ist eine andere Sicherheitshaltung als die der meisten Web-Apps, in denen jedes importierte Paket mit derselben Autorität wie die App selbst läuft. Innerhalb von SSP teilten sich der Code, der private Schlüssel verwaltet, die Swap-Integration, die mit Exchange-APIs spricht, und die UI-Helfer von Drittanbietern bislang einen einzigen globalen Scope. Seit v1.27.0 nicht mehr.
Warum Compartmentalization wichtig ist
Die Bedrohung, die Compartmentalization neutralisieren soll, ist der npm-Lieferkettenangriff. Das Muster wurde mehrfach in freier Wildbahn beobachtet: Ein Angreifer übernimmt ein populäres Paket, veröffentlicht eine bösartige Version und reitet auf der Welle der transitiven Abhängigkeiten in jede App, die es importiert. Für ein Wallet ist die Wirkung eines bösartigen Pakets, das mit voller App-Autorität läuft, katastrophal — es kann Seed-Material im Speicher lesen, private Schlüssel exfiltrieren oder Transaktionsziele umschreiben, bevor der Nutzer signiert.
LavaMoat verhindert nicht, dass der Angriff die App erreicht. Es entfernt die Wirkung. Eine kompromittierte Abhängigkeit — selbst eine, die fünf Ebenen tief im Baum vergraben ist — läuft in einem Kompartment, das keinen Zugriff auf die Signier-Oberfläche hat, keinen Netzwerkzugriff jenseits dessen, was die Policy erlaubt, und keine Möglichkeit, den Zustand eines anderen Kompartments zu lesen. Kompromittiertes Paket ≠ kompromittiertes Wallet — die Gleichung hält zum ersten Mal in v1.27.0.
Das ergänzt die Schutzmaßnahmen, die früher im Jahr eintrafen, statt sie zu ersetzen. SSPs Quellcode wurde bereits durch den vollständigen Halborn-Audit verifiziert, und das Binary, das du installierst, war bereits gegen diesen Quellcode prüfbar — über deterministische Builds und GPG-Signing. LavaMoat schließt die Laufzeit-Lücke: Selbst wenn eine Abhängigkeit bösartig wird, nachdem der Build signiert ist, kann sie nicht auf Wallet-Ebene eskalieren.
Schärfere Content Security Policy
Neben dem Laufzeit-Sandboxing verschärft v1.27.0 auch die Content Security Policy auf Browser-Ebene. Die CSP ist das Budget, das das Wallet für sich selbst deklariert — von welchen Ursprüngen es Skripte laden darf, mit welchen Ursprüngen es sprechen darf, welche Inline-Verhaltensweisen erlaubt sind. Eine strengere CSP verkleinert den Raum, in dem ein Angreifer operieren kann, schon bevor LavaMoat seine Policy innerhalb der Seite durchsetzt.
Der kombinierte Effekt sind zwei Eindämmungsschichten: Der Browser weigert sich, Ressourcen außerhalb der deklarierten Policy zu laden, und jedes JavaScript, das doch läuft, wird anschließend von LavaMoat compartmentalized. Jede Schicht deckt einen anderen Fehlerfall ab — genau der Sinn von Defense in Depth.
Eine versteckte Sicherheits-Testseite
Für interne Verifikation — und das ist das einzige Feature in der Release, das mit einem absichtlichen Easter Egg ausgeliefert wird — enthält v1.27.0 eine Sicherheits-Testseite, die in der normalen Navigation nicht sichtbar ist. Mehrfaches Klicken auf die Versionsnummer in schneller Folge bringt sie zum Vorschein. Die Seite läuft eine Batterie von Checks gegen die LavaMoat-Policy und die CSP-Regeln, damit Reviewer und Red-Teamer bestätigen können, dass die Schutzmaßnahmen in dem Build, den sie inspizieren, aktiv sind, ohne das Wallet selbst instrumentieren zu müssen. Sie ist nicht für den Alltagsgebrauch gedacht, und dahinter steckt nichts Ausnutzbares; sie ist nur eine bequemere Möglichkeit, zu verifizieren, was v1.27.0 verspricht.
Defense in Depth: auditiert + reproduzierbar + sandboxed
Das Interessante an v1.27.0 ist nicht LavaMoat in Isolation, sondern wie die drei Stücke zusammenspielen. Auditierter Quellcode (Halborn), reproduzierbares Binary, das jeder gegen diesen Quellcode prüfen kann (deterministische Builds), und ein Runtime, das jede kompromittierte Abhängigkeit eindämmt. Zusammen verschieben sie die Frage von „Vertraue ich dem gesamten Abhängigkeitsbaum von SSP?" zu „Vertraue ich dem auditierten Kern?" — eine deutlich kleinere und beantwortbarere Vertrauensfläche.
UI-Politur kommt obendrauf: Swap-Exchange-Logos werden jetzt korrekt gerendert, und die Markenfarbpalette wurde über die Screens hinweg angeglichen. Die Compartmentalization ist das, was verändert, wie das Wallet überlebt.