SEAL Certifications — программа сертификации операционной безопасности с открытым исходным кодом, опубликованная Security Alliance (SEAL). Её действующая базовая версия объединяет 99 конкретных операционных требований, называемых контролями, в шесть модулей. Они охватывают персонал, учётные записи, подписантов, домены, инфраструктуру, процессы управления казначейством и возможности реагирования, связанные с криптопротоколом [1, 2].
BlockSec — одна из первых аккредитованных оценочных организаций программы и в настоящее время единственная из них со штаб-квартирой в Азии. Как оценочная организация, аккредитованная SEAL, мы согласовываем с клиентом объём оценки, оцениваем выбранные контроли и доказательства, документируем пробелы и определяем, выполнены ли требования в согласованном объёме. Если требования выполнены, мы выпускаем ончейн-аттестацию в рамках нашей аккредитации SEAL [4].
В этой статье объясняется, почему организация может стремиться получить сертификацию SEAL, что означает её результат, какие модули могут применяться, как мы проводим оценку и как команда может подготовиться к работе с нами.
1. Зачем проходить сертификацию SEAL
Обоснование этой системы требований, предложенное SEAL, состоит в том, что основным источником эксплойтов в криптоиндустрии стали не уязвимости смарт-контрактов, а операционные сбои [1]. Поэтому при оценке внимание смещается на контроли, связанные с подписантами, мультиподписными кошельками, доменами, учётными данными, мониторингом инфраструктуры и реагированием на инциденты. Оценка для сертификации SEAL позволяет выяснить, действуют ли эти контроли на практике и можно ли подтвердить их работу доказательствами. Благодаря этому криптоорганизации получают независимое заключение о том, какие контроли соответствуют базовым требованиям и где сохраняются пробелы [1, 3].
Сертификация SEAL отвечает на один вопрос, касающийся подтверждения надёжности: прошли ли операционные контроли в согласованном объёме независимую оценку и признаны ли они соответствующими опубликованным базовым требованиям к операционной безопасности, разработанным специально для криптоиндустрии? Криптоорганизациям — например, протоколам, биржам, платёжным платформам и кастодианам — такое подтверждение может понадобиться, когда инвесторы, команды, отвечающие за листинг, заинтересованные стороны в сфере комплаенса, внутренние органы управления, страховщики или специалисты, проводящие комплексную проверку, запрашивают независимые доказательства работы операционных контролей. В результате указываются оценённые модули и границы оценки, а также фиксируется, соответствовал ли этот объём базовым требованиям [5, 6].
Пределы такого подтверждения становятся яснее при сравнении со смежными видами проверки безопасности. Оценка может охватывать операционные доказательства, связанные с кодом, для контролей репозиториев, CI/CD и инфраструктуры: разрешения, настройки защиты веток, записи о проверке кода, результаты сканирования безопасности, контроли конвейеров и конфигурации инфраструктуры [7]. При этом исходный код не проверяется на уязвимости реализации и не определяется корректность логики протокола [1]. В таблице ниже сертификация SEAL сравнивается с аудитом кода и тестированием на проникновение.
| Сравнение | Сертификация SEAL | Аудит кода | Тестирование на проникновение |
|---|---|---|---|
| Основной предмет оценки | Операционные контроли и подтверждающие доказательства в пределах согласованных модулей и границ | Исходный код и логика протокола в пределах согласованного объёма аудита | Системы и поверхности атаки в пределах согласованной среды и правил проведения проверки |
| Главный вопрос | Соответствуют ли операционные контроли в объёме оценки требованиям SEAL и подкреплены ли они достаточными доказательствами? | Содержит ли код в объёме оценки уязвимости реализации или ошибки логики протокола? | Можно ли воспроизвести путь эксплуатации уязвимости в согласованной среде? |
| Подход к оценке | Проверка реализации контролей по документации, операционным записям, конфигурациям, интервью и, где уместно, результатам тестирования | Проверка исходного кода в объёме аудита и сопутствующих спецификаций на предмет ошибок реализации и логики | Проверка согласованных поверхностей атаки и подтверждение того, можно ли использовать выявленные слабые места в рамках правил проведения проверки |
| Результат | Сертификация и соответствующая ончейн-аттестация, если требования в согласованном объёме выполнены; сведения о пробелах, если требования не выполнены | Выявленные проблемы безопасности и рекомендации по их устранению для объёма аудита | Выявленные проблемы безопасности и рекомендации по их устранению для объёма тестирования |
Эти услуги решают разные задачи оценки. Тестирование может предоставить доказательства для некоторых контролей SEAL, но ни аудит, ни тестирование на проникновение сами по себе не обеспечивают сертификацию SEAL.
Сертификация SEAL — самостоятельная программа оценки. Сертификат выдаётся только в том случае, если выбранный объём соответствует требованиям SEAL [6]. Аудит кода и тестирование на проникновение — отдельные виды деятельности; ни один из них не является обязательным условием сертификации.
То же разграничение касается и более широких стандартов подтверждения надёжности. Согласно публикации SEAL с запросом комментариев, SOC 2 и ISO 27001 сохраняют ценность и в конечном счёте будут необходимы многим организациям, но они не разрабатывались с учётом специфичных для криптоиндустрии моделей работы, например небольших распределённых команд, контролирующих значительные объёмы ончейн-активов [5]. Система требований SEAL служит более узконаправленной отправной точкой для операционных контролей в криптоиндустрии и может применяться наряду с этими более широкими стандартами.
2. Что подтверждает сертификация
Результат сертификации SEAL относится к операционным контролям, модулям и границам, выбранным для оценки. Когда выбранные контроли соответствуют требованиям SEAL, аккредитованная SEAL оценочная организация, такая как BlockSec, в рамках своей аккредитации выпускает через Ethereum Attestation Service ончейн-аттестацию вместе с соответствующим знаком SEAL [4]. Аттестация общедоступна; подробные отчёты об оценке и доказательства остаются конфиденциальными и доступны только оценочной организации и клиенту [1]. Таблица отделяет выводы, которые подтверждает положительный результат, от утверждений, выходящих за его пределы.
| Положительный результат сертификации SEAL подтверждает... | Он не подтверждает... |
|---|---|
| Что оценённая организация выполнила требования SEAL для модулей и границ согласованного объёма | Что оценивались модули или операционные системы, не указанные в объёме оценки |
| Что операционные контроли и подтверждающие доказательства в объёме оценки прошли независимую проверку третьей стороной | Что исходный код проверялся на ошибки реализации, что тестировались пути атаки или что в протоколе нет уязвимостей |
| Соответствие каждого контроля в согласованном объёме | Оценку безопасности в баллах, уровень зрелости, заключение о качестве кода или одобрение регулятора |
| Сертификацию, действующую в течение ограниченного срока и отражающую состояние на момент оценки, которая требует повторной оценки | Непрерывное соответствие требованиям или гарантию отсутствия инцидентов |
Эти ограничения сохраняются и после выпуска аттестации. Аттестация SEAL не означает, что в протоколе отсутствуют проблемы безопасности [1]. Срок её действия ограничен, требуется периодическая повторная оценка, а при длительном несоблюдении требований она может быть отозвана; SEAL не публикует фиксированный срок действия [1].
3. Что охватывает система требований
Шесть модулей можно оценивать по отдельности или вместе. Действующая базовая версия содержит 99 контролей [1, 2]. Столбец When it may apply служит редакционным ориентиром, составленным на основе определений модулей, а не официальным правилом SEAL для определения объёма оценки; окончательный объём мы согласовываем с клиентом в ходе работы.
| Модуль | Что охватывает | Когда может применяться |
|---|---|---|
| Операции с мультиподписью (24 контроля) | Настройка подписантов, выполнение транзакций, координация, непрерывность работы и действия в чрезвычайных ситуациях | Мультиподписные кошельки, группы подписантов или согласованное утверждение транзакций |
| Операции казначейства (23 контроля) | Архитектура хранения активов, управление активами, управление порядком проведения транзакций, сверка, мониторинг, управление поставщиками услуг, страхование и реагирование казначейства | Казначейские активы, распределение активов, отношения с кастодианами или движение средств |
| Реагирование на инциденты (13 контролей) | Подготовка, эскалация, коммуникации, планы действий, учения и скоординированное реагирование | Команда, которой необходимо обнаруживать и локализовывать инциденты безопасности, сообщать о них и восстанавливать работу после них |
| DevOps и инфраструктура (15 контролей) | Управление репозиториями, контроли проверки и сканирования кода, CI/CD, управление цепочкой поставок, доступ к инфраструктуре, мониторинг и устойчивость | Репозитории кода, конвейеры развёртывания, облачная инфраструктура или администрирование продуктивной среды |
| DNS и регистратор (16 контролей) | Владение доменами, доступ к регистратору, конфигурация DNS, мониторинг, восстановление и реагирование на захват | Критически важные домены, учётные записи регистраторов, записи DNS или аутентификация электронной почты |
| Идентификация и учётные записи (8 контролей) | Учёт учётных записей, ответственность за них, устойчивая к фишингу аутентификация, управление учётными данными, восстановление, проверка прав доступа, управление жизненным циклом, мониторинг и доступ третьих сторон | Учётные записи пользователей, сервисов или привилегированные учётные записи в репозиториях, облачных платформах, у регистраторов, в системах хранения активов или внутренних инструментах |
Подробнее о модуле DNS и регистратор — в статье За пределами смарт-контракта: операционная безопасность доменов и DNS в Web3.
Модули остаются связаны на операционном уровне, даже если оцениваются независимо. Некоторые контроли модулей DevOps и инфраструктура и DNS и регистратор опираются на практики безопасности учётных записей, определённые в модуле Идентификация и учётные записи. Требования к реагированию на инциденты также присутствуют в нескольких модулях — например, требования к координации подписантов мультиподписного кошелька или восстановлению учётных записей во время инцидента [2].
Эти межмодульные связи влияют на доказательства, необходимые для контроля в объёме оценки; они не означают автоматической сертификации модуля, на который ссылаются, не создают обязательного порядка сертификации и не расширяют объём оценки. Аттестация по модулю DNS и регистратор не становится аттестацией по модулю Идентификация и учётные записи лишь потому, что контроль DNS опирается на практики безопасности учётных записей. Аттестация относится только к модулям и границам, указанным в её объёме [1, 6].
4. Как проходит оценка
SEAL поддерживает систему требований и управляет программой сертификации. Как оценочная организация, аккредитованная SEAL, мы проводим оценку каждого клиента в пять этапов [1, 4]:
Рисунок 1. Работа по сертификации SEAL проходит от согласования объёма через проверку доказательств, устранение пробелов и повторную оценку к выпуску аттестации.
-
Определение объёма. Мы согласовываем с клиентом, какие модули, контроли, системы, операции и организационные границы входят в объём оценки.
-
Сбор доказательств. Клиент предоставляет материалы, показывающие, как разработаны контроли в объёме оценки, кто за них отвечает, как они применяются и проверяются.
-
Оценка. Мы оцениваем эти доказательства на соответствие опубликованным требованиям SEAL и выявляем отсутствующие или недостаточные подтверждения.
-
Устранение пробелов и повторная оценка. Если согласованный объём не соответствует базовым требованиям, мы предоставляем отчёт о пробелах. Клиент устраняет выявленные пробелы и направляет обновлённые доказательства для повторной оценки.
-
Сертификация. Когда согласованный объём соответствует базовым требованиям, мы выпускаем официальную ончейн-аттестацию в рамках нашей аккредитации SEAL.
Сбор доказательств и оценка взаимосвязаны: клиент предоставляет подтверждающие материалы, а BlockSec оценивает, доказывают ли они, что каждый контроль действует на практике. Руководство SEAL по сертификации делит подтверждающие доказательства на пять категорий. Ниже они приведены с примерами из руководства и базовых требований модулей [2, 3, 7]:
| Категория доказательств | Что помогает подтвердить |
|---|---|
| Документация процедур | Предусмотренный контроль, включая политики, версии и даты утверждения |
| Подтверждение практического применения | Что процесс применяется на практике, — с помощью журналов, записей, заявок или интервью с членами команды |
| Тестирование/проверка | Что защитная мера или процесс реагирования были отработаны либо проверены |
| Сведения об ответственных | Кто поддерживает контроль, как часто он проверяется и когда обновлялся в последний раз |
| Технические артефакты | Конфигурации, снимки экрана или выгрузки из систем, включая настройки репозиториев и CI/CD, облачные конфигурации, выгрузки регистратора или DNS и другие технические доказательства в объёме оценки |
На основании этих доказательств BlockSec фиксирует статус каждого контроля в объёме оценки как «Реализован», «Частично реализован», «Не реализован» или «Неприменимо» с обоснованием. Для официальной сертификации контроли в согласованном объёме должны иметь статус «Реализован» или обоснованный статус «Неприменимо», а заявленные статусы должны подкрепляться доказательствами. Таким образом, решение о сертификации для всего согласованного объёма имеет два возможных исхода, хотя сама оценка проводится отдельно по каждому контролю [3, 6].
5. Как подготовиться
Перед началом работы по сертификации SEAL подготовьте четыре вещи:
-
Предлагаемый объём: модули, системы, юридические лица, команды и границы, существенные для того, что предполагается подтвердить сертификацией.
-
Самооценку каждого контроля: какие требования предположительно имеют статус «Реализован», «Частично реализован», «Не реализован» или «Неприменимо», с обоснованием каждого ответа.
-
Реестр доказательств: существующие процедуры, операционные записи, результаты тестирования, сведения об ответственных и технические артефакты, соотнесённые с предлагаемым объёмом.
-
Назначенных участников: людей, ответственных за решения об объёме оценки, сбор доказательств и координацию устранения пробелов.
Поскольку система требований и контрольные списки общедоступны, команда может приступить к этой работе ещё до официального начала оценки. Самооценка помогает выявить недокументированные процессы, недостающие доказательства практической работы, контроли без назначенных ответственных и известные задачи по устранению пробелов. При этом она остаётся внутренней контрольной точкой: её результаты не проверяются независимо и не приводят к выпуску аттестации SEAL [1, 3].
Эти четыре пункта помогают первоначально определить объём; подробный перечень запрашиваемых материалов зависит от выбранных модулей. Приведённые выше названия модулей обозначают предметные области, а не обязательную последовательность сертификации. По мере публикации отдельных статей в них будут появляться рекомендации по контролям на уровне модулей. Чтобы обсудить выбор модулей, готовность доказательств и объём оценки, свяжитесь с нами по адресу [email protected].
Источники
- Security Alliance, Обзор системы требований сертификации SEAL.
- Security Alliance, Экспорт всех сертификаций (XLSX), доступен на странице обзора системы требований. Количество контролей и межмодульные связи также сверены с шестью опубликованными страницами модулей в октябре 2026 года.
- Security Alliance, Руководство по сертификации.
- Security Alliance, Аккредитация аудиторов; SEAL Certifications.
- Security Alliance Radar, Запрос комментариев: SEAL Certifications.
- Isaac Patka, Security Alliance Radar, SEAL Certifications: программа открыта для участников (02.06.2026).
- Security Alliance, SFC: DevOps и инфраструктура.
