Was ist die SEAL-Zertifizierung? Sicherstellung der operativen Sicherheit für Krypto

SEAL Certifications ist ein von Security Alliance (SEAL) veröffentlichtes Open-Source-Zertifizierungsprogramm für operative Sicherheit. Seine aktuelle Grundlage in Version v0.0.1 umfasst 99 spezifische operative Anforderungen, die als Kontrollen bezeichnet werden. Sie verteilen sich auf sechs Module für Personen, Konten, Signierende, Domains, Infrastruktur, Treasury-Prozesse und Reaktionsfähigkeiten im Umfeld eines Kryptoprotokolls [1, 2].

BlockSec gehört zu den ersten akkreditierten Prüfern des Programms und ist derzeit der einzige akkreditierte Prüfer mit Hauptsitz in Asien. Als von SEAL akkreditierter Prüfer legen wir gemeinsam mit dem Kunden den Prüfungsumfang fest, bewerten die ausgewählten Kontrollen und Nachweise, dokumentieren Lücken und stellen fest, ob die Anforderungen im festgelegten Umfang erfüllt sind. Ist dies der Fall, stellen wir im Rahmen unserer SEAL-Akkreditierung die On-Chain-Attestierung aus [4].

Dieser Artikel erläutert, warum eine Organisation eine SEAL-Zertifizierung anstreben kann, was die Zertifizierung aussagt, welche Module infrage kommen, wie wir die Prüfung durchführen und wie sich ein Team darauf vorbereiten kann.

1. Warum eine SEAL-Zertifizierung anstreben?

SEAL begründet das Framework damit, dass sich die Hauptursache von Exploits im Kryptobereich von Schwachstellen in Smart Contracts hin zu operativen Fehlern verlagert hat [1]. Bei einer Prüfung rücken damit die Kontrollen für Signierende, Multisigs, Domains, Zugangsdaten, Infrastrukturüberwachung und Incident Response in den Vordergrund. Eine SEAL-Zertifizierungsprüfung untersucht, ob diese Kontrollen in der Praxis funktionieren und sich belegen lassen. So erhalten Kryptoorganisationen eine unabhängige Einschätzung dazu, welche Kontrollen die Grundanforderungen erfüllen und wo Lücken bestehen [1, 3].

Die SEAL-Zertifizierung beantwortet eine Frage zur Sicherheitsgewährleistung: Wurden die operativen Kontrollen innerhalb eines vereinbarten Umfangs unabhängig geprüft und wurde festgestellt, dass sie eine öffentliche, speziell für den Kryptobereich entwickelte Grundlage für operative Sicherheit erfüllen? Kryptoorganisationen wie Protokolle, Börsen, Zahlungsplattformen und Verwahrstellen benötigen diese Gewissheit möglicherweise, wenn Investoren, Listing-Teams, Compliance-Verantwortliche, interne Leitungsgremien, Versicherer oder Due-Diligence-Prüfer unabhängige Nachweise für ihre operativen Kontrollen verlangen. Das Ergebnis benennt die geprüften Module und Grenzen und hält fest, ob dieser Umfang die Grundanforderungen erfüllt hat [5, 6].

Der Umfang dieser Gewissheit wird im Vergleich mit angrenzenden Sicherheitsmaßnahmen deutlicher. Die Prüfung kann codebezogene operative Nachweise für Repository-, CI/CD- und Infrastrukturkontrollen untersuchen: Berechtigungen, Branch-Protection-Einstellungen, Aufzeichnungen zu Code-Reviews, Ergebnisse von Sicherheitsscans, Pipeline-Kontrollen und Infrastrukturkonfigurationen [7]. Sie prüft keinen Quellcode auf Implementierungsschwachstellen und stellt nicht fest, ob die Protokolllogik korrekt ist [1]. Andere Sicherheitsmaßnahmen verfolgen diese und verwandte Ziele: Ein Code Audit bewertet Quellcode auf Implementierungsschwachstellen und Fehler in der Protokolllogik; Penetration Testing prüft, ob sich ausnutzbare Angriffspfade in einer vereinbarten Umgebung reproduzieren lassen; Bug-Bounty-Programme bieten einen fortlaufenden Kanal für externe Erkenntnisse; und kontinuierliche Überwachung unterstützt die laufende Erkennung und Reaktion.

Die SEAL-Zertifizierung ist ein eigenständiges Prüfprogramm. Eine Zertifizierung wird nur ausgestellt, wenn der ausgewählte Umfang die Anforderungen von SEAL erfüllt [6]. Code Audit, Penetration Testing, Bug-Bounty-Programme und kontinuierliche Überwachung sind separate Maßnahmen; keine davon ist Voraussetzung für die Zertifizierung.

Die gleiche Unterscheidung gilt für umfassendere Standards zur Sicherheitsgewährleistung. Laut dem Aufruf von SEAL zur Stellungnahme sind SOC 2 und ISO 27001 weiterhin wertvoll und werden für viele Organisationen letztlich notwendig sein. Sie wurden jedoch nicht für kryptospezifische Betriebsmodelle konzipiert, bei denen etwa kleine, verteilte Teams erhebliche On-Chain-Werte kontrollieren [5]. Das SEAL-Framework bietet einen gezielteren Ausgangspunkt für operative Kontrollen im Kryptobereich und kann diese umfassenderen Standards ergänzen.

2. Was die Zertifizierung belegt

Ein SEAL-Zertifizierungsergebnis gilt für die operativen Kontrollen, Module und Grenzen, die für den Auftrag ausgewählt wurden. Wenn die ausgewählten Kontrollen die Anforderungen von SEAL erfüllen, stellt eine von SEAL akkreditierte Prüffirma wie BlockSec im Rahmen ihrer Akkreditierung über den Ethereum Attestation Service die On-Chain-Attestierung zusammen mit dem entsprechenden SEAL-Badge aus [4]. Die Attestierung ist öffentlich; detaillierte Prüfberichte und Nachweise bleiben zwischen der Prüffirma und dem Kunden vertraulich [1]. Die Tabelle trennt die Aussagen, die ein positives Ergebnis stützt, von Aussagen außerhalb seines Geltungsbereichs.

Diese Grenzen gelten auch nach der Ausstellung. Eine SEAL-Attestierung besagt nicht, dass ein Protokoll frei von Sicherheitsproblemen ist [1]. Sie ist befristet, erfordert regelmäßige erneute Prüfungen und kann bei anhaltender Nichteinhaltung widerrufen werden; SEAL veröffentlicht keine feste Gültigkeitsdauer [1].

3. Was das Framework abdeckt

Die sechs Module können einzeln oder gemeinsam geprüft werden. Die aktuelle Grundlage enthält 99 Kontrollen [1, 2]. Die Spalte Wann es relevant sein kann ist eine redaktionelle Orientierung auf Basis der Moduldefinitionen und keine offizielle Regel von SEAL zur Festlegung des Prüfungsumfangs; den endgültigen Umfang stimmen wir im Rahmen des Auftrags mit dem Kunden ab.

Die Module bleiben operativ miteinander verbunden, auch wenn sie unabhängig voneinander geprüft werden. Einige Kontrollen in DevOps & Infrastructure und DNS & Registrar stützen sich auf Sicherheitspraktiken für Konten, die unter Identity & Accounts definiert sind. Anforderungen an die Reaktion auf Vorfälle finden sich ebenfalls in mehreren Modulen, etwa zur Koordination von Multisig-Signierenden oder zur Wiederherstellung von Konten während eines Vorfalls [2].

Diese modulübergreifenden Verweise beeinflussen, welche Nachweise für eine einbezogene Kontrolle erforderlich sind; sie zertifizieren das referenzierte Modul nicht automatisch, legen keine vorgeschriebene Zertifizierungsreihenfolge fest und erweitern den Auftrag nicht. Eine Attestierung für DNS & Registrar wird nicht allein deshalb zu einer Attestierung für Identity & Accounts, weil eine DNS-Kontrolle auf Sicherheitspraktiken für Konten beruht. Die Attestierung gilt nur für die Module und Grenzen, die in ihrem Umfang genannt sind [1, 6].

4. Wie die Prüfung abläuft

SEAL pflegt das Framework und betreibt das Zertifizierungsprogramm. Als von SEAL akkreditierte Prüffirma führen wir jede Kundenprüfung in fünf Schritten durch [1, 4]:

Abbildung 1. Ein SEAL-Zertifizierungsauftrag führt vom vereinbarten Umfang über Nachweisprüfung, Behebung von Lücken und erneute Prüfung bis zur Ausstellung einer Attestierung.

1. Festlegung des Prüfungsumfangs. Wir vereinbaren mit dem Kunden, welche Module, Kontrollen, Systeme, Betriebsabläufe und organisatorischen Grenzen einbezogen werden.

2. Sammlung von Nachweisen. Der Kunde stellt Unterlagen bereit, die zeigen, wie die einbezogenen Kontrollen gestaltet, zugewiesen, durchgeführt und überprüft werden.

3. Prüfung. Wir bewerten diese Nachweise anhand der veröffentlichten Anforderungen von SEAL und identifizieren fehlende oder unzureichende Belege.

4. Behebung von Lücken, falls erforderlich. Wenn der vereinbarte Umfang die Grundanforderungen nicht erfüllt, stellen wir einen Bericht über die Lücken bereit. Der Kunde behebt die festgestellten Lücken und reicht aktualisierte Nachweise zur erneuten Prüfung ein.

5. Zertifizierung. Wenn der vereinbarte Umfang die Grundanforderungen erfüllt, stellen wir im Rahmen unserer SEAL-Akkreditierung die formelle On-Chain-Attestierung aus.

Nachweissammlung und Prüfung greifen ineinander: Der Kunde stellt unterstützende Unterlagen bereit, und BlockSec bewertet, ob diese belegen, dass jede Kontrolle in der Praxis funktioniert. Die Certification Guidelines von SEAL teilen unterstützende Nachweise in fünf Kategorien ein, die nachstehend mit Beispielen aus den Richtlinien und der Modulgrundlage zusammengefasst sind [2, 3, 7]:

Anhand dieser Nachweise erfasst BlockSec jede einbezogene Kontrolle als Implemented, Partially Implemented, Not Implemented oder N/A mit Begründung. Für eine formelle Zertifizierung müssen die Kontrollen im vereinbarten Umfang Implemented oder begründet als N/A eingestuft sein; die Angaben müssen durch Nachweise gestützt werden. Die Zertifizierungsentscheidung für den gesamten vereinbarten Umfang lautet somit entweder bestanden oder nicht bestanden, auch wenn die zugrunde liegende Prüfung für jede Kontrolle einzeln erfolgt [3, 6].

5. Wie Sie sich vorbereiten können

Bereiten Sie vor Beginn eines SEAL-Zertifizierungsauftrags vier Dinge vor:

1. Einen vorgeschlagenen Prüfungsumfang: die Module, Systeme, Organisationseinheiten, Teams und Grenzen, die für die beabsichtigte Zertifizierungsaussage relevant sind.

2. Eine Selbstbewertung jeder einzelnen Kontrolle: welche Anforderungen als Implemented, Partially Implemented, Not Implemented oder N/A erscheinen, jeweils mit der Grundlage für die Einstufung.

3. Ein Nachweisverzeichnis: vorhandene Verfahren, Betriebsaufzeichnungen, Testergebnisse, Aufzeichnungen zu Zuständigkeiten und technische Artefakte, die dem vorgeschlagenen Umfang zugeordnet sind.

4. Benannte Beteiligte: die Personen, die für Entscheidungen über den Umfang, die Sammlung von Nachweisen und die Koordination der Behebung von Lücken verantwortlich sind.

Da das Framework und die Checklisten öffentlich sind, kann ein Team mit diesen Arbeiten schon vor einem formellen Auftrag beginnen. Eine Selbstbewertung hilft dabei, undokumentierte Prozesse, fehlende Nachweise aus dem Betrieb, Kontrollen ohne Zuständigkeit und bekannte Arbeiten zur Behebung von Lücken zu erkennen. Sie bleibt jedoch eine interne Bestandsaufnahme: Sie wird nicht unabhängig überprüft und führt nicht zu einer SEAL-Attestierung [1, 3].

Diese vier Punkte unterstützen die anfängliche Festlegung des Prüfungsumfangs; welche Unterlagen im Einzelnen angefordert werden, hängt von den ausgewählten Modulen ab. Die oben genannten Modulnamen bezeichnen Themenbereiche, keine vorgeschriebene Zertifizierungsreihenfolge. Eigene Artikel werden nach ihrer Veröffentlichung Hinweise zu den Kontrollen der einzelnen Module geben. Bitte kontaktieren Sie uns [需实证:CONTACT_OR_RELEVANT_PAGE_URL], um die Modulauswahl, die Verfügbarkeit von Nachweisen und den Auftragsumfang zu besprechen.

Quellen

1. Security Alliance, SEAL Certification Framework: Overview. Begründung des Frameworks, Module, unabhängige Festlegung des Prüfungsumfangs, Prüfungsablauf, Selbstbewertung, Attestierung und Badge, Vertraulichkeit, erneute Prüfung und Widerruf. https://frameworks.securityalliance.org/certs/overview/

2. Security Alliance, Export All Certifications (XLSX). Aktuelle Anzahl der Kontrollen je Modul und modulübergreifende Verweise, anhand des offiziellen Exports aus der Übersicht des SEAL Certification Framework überprüft; abgerufen im September 2026. https://frameworks.securityalliance.org/certs/overview/

3. Security Alliance, Certification Guidelines. Status jeder einzelnen Kontrolle, Zertifizierungskriterien und Nachweiskategorien. https://frameworks.securityalliance.org/certs/certification-guidelines/

4. Security Alliance, Auditor Accreditation; und SEAL Certifications. Akkreditierungsverfahren, Verantwortlichkeiten der Prüffirmen, Programmstatus und aktuelle öffentliche Informationen zu Partnern. https://frameworks.securityalliance.org/certs/certified-partners/ und https://securityalliance.org/our-work/certifications

5. Security Alliance Radar, Request for Comments: SEAL Certifications. Reifegrad der Sicherheit von Smart Contracts, Einordnung von SOC 2 und ISO 27001 sowie Begründung von Modularität und Überprüfbarkeit. https://radar.securityalliance.org/request-for-comments-seal-certifications/

6. Security Alliance Radar, SEAL Certifications: Now Open for Business (Isaac Patka, 2. Juni 2026). Überblick über die sechs Bereiche und die einheitliche Entscheidung über Bestehen oder Nichtbestehen für den vereinbarten Umfang. https://radar.securityalliance.org/seal-certifications-auditor-accreditations-protocol-assessments/

7. Security Alliance, SFC: DevOps & Infrastructure. Öffentliche Grundanforderungen für Repository-Berechtigungen, Branch Protection, Kontrollen für Code-Reviews und Scans, CI/CD, Lieferkettenmanagement und Infrastrukturkonfiguration. https://frameworks.securityalliance.org/certs/sfc-devops-infrastructure/