Тестирование блокчейна на проникновение для криптоорганизаций

Потому что самые крупные потери всё чаще возникают за пределами смарт-контрактов: при подписании, хранении активов, работе с ключами, людьми и цепочками поставок.

По нашим данным за 2026 год (потери свыше 100 000 долларов), на сбои вне уровня контрактов приходилось примерно одно из восьми происшествий, но более трёх четвертей потерь.

Аудит кода исследует код; мониторинг транзакций — транзакции при их поступлении в блокчейн. Ни тот, ни другой не восстанавливает путь между ними.

Пример — компрометация Bybit в 2025 году: подменённый интерфейс подписания превратил согласование самих операторов в перевод, которого они не намеревались совершать, при этом контракт, его аудит и мониторинг могли по отдельности считать такой перевод законным.

Другие разборы BlockSec: похищенный API-ключ в официальном канале обновлений, уязвимость генератора адресов Profanity, сбой энтропии аппаратного кошелька.

Разница — в цели подтверждения безопасности.

Аудит формирует уверенность в коде, включая проектирование, архитектуру и допущения протокола. Пентест выясняет, можно ли связать реальные условия работающей среды организации в цепочку с воспроизводимыми последствиями.

Один аудит не даёт доказательств возможности эксплуатации уязвимостей в работающей среде всей организации, а пентест не заменяет подтверждения безопасности на уровне кода. Методы пересекаются, и команды могут работать совместно.

Традиционное тестирование на проникновение важно для облака, веб-приложений, API, идентификации и привилегированного доступа. Но ему часто недостаёт понимания бизнес-смысла криптоопераций: подпись может разрешить необратимое перемещение средств, а согласование вывода — это решение о контроле средств, а не отправка формы.

Тестировщик может обнаружить обход аутентификации, но не увидеть, как он сочетается с несоответствием отображаемых и подписываемых данных или слабой политикой согласования, образуя путь к средствам.

Обычный тест доказывает влияние на ИТ-контроли; здесь конечным условием считается перемещение средств. Различие заключается в специализированной экспертизе безопасности Web3, а не в новых инструментах.

Для определённых категорий лицензированных организаций — да. Обязанность зависит от условий и не универсальна; объём, периодичность и требования к независимости различаются по рынкам.

• Нью-Йорк (NYDFS Part 500): организации, подпадающие под регулирование, включая лицензированные DFS компании виртуальных валют, должны как минимум ежегодно проводить тестирование на проникновение изнутри и снаружи границ информационных систем силами квалифицированной внутренней или внешней стороны. Небольшие организации, соответствующие порогам этого нормативного акта, получают ограниченное освобождение от раздела о тестировании, но остаются связанными другими применимыми положениями Part 500.
• Дубай (VARA): лицензированные VASP должны проводить оценку уязвимостей и тестирование на проникновение как минимум ежегодно и до внедрения новых систем, приложений или продуктов с привлечением квалифицированной независимой третьей стороны.
• Гонконг (SFC): заявители VATP, считающиеся лицензированными, должны до начала ограниченной деятельности пройти тестирование на проникновение и оценку уязвимостей с удовлетворительными результатами у независимой третьей стороны.
• Европейский союз (DORA): финансовые организации, кроме микропредприятий, должны обеспечивать надлежащее тестирование систем, поддерживающих критические или важные функции, как минимум ежегодно. Тестирование на проникновение на основе угроз применяется только к организациям, определённым компетентным органом, проводится в рабочих системах и обычно требуется не реже одного раза в три года.
• Сингапур (MAS TRM Guidelines): необязательное надзорное ожидание — тестировать доступные через интернет системы как минимум ежегодно или после существенных изменений.

Регуляторы требуют тестирования на проникновение, но не называют фирменную категорию услуги. Специализацию определяют системы в объёме работ: если они авторизуют, подписывают, хранят или учитывают криптоактивы, качественная проверка требует понимания подписания и движения средств.

Эти примеры носят иллюстративный характер и не являются юридической консультацией. Организациям следует уточнять свой статус, исключения и обязательства у юристов.

Объём согласуется индивидуально. Он может включать облако, веб-приложения, API, идентификацию и эксплуатационные системы, если они связаны с путём к средствам. Мы также проверяем четыре взаимосвязанные части цепочки операций со средствами Web3:

• Веб- и dApp-интерфейсы, авторизация и намерение подписания
• Цепочки полномочий на подписание, согласование и вывод
• Бизнес-логика операций со средствами
• Транзакции в блокчейне и развёрнутые контракты

Подтверждение безопасности контрактов на уровне кода остаётся задачей соответствующего аудита кода.

Только при письменном разрешении и согласованных мерах безопасности, зафиксированных до начала тестирования в документе «Правила проведения работ».

Правила разделяют включённое в объём и разрешённые действия: рабочий сервис вывода может входить в проверку пути авторизации, при этом реальные клиентские выводы, экспорт приватных ключей, закрепление и атаки с созданием нагрузки остаются запрещёнными.

Для процессов подписания и вывода контролируемые сценарии определяют выделенные кошельки, разрешённые адреса назначения и максимальную тестовую сумму, участников согласования и сверку ончейн-активности, бухгалтерских записей и балансов.

С владельцем сервиса согласуются измеримые критерии остановки, защищённый канал безопасности и конкретное уполномоченное лицо для приостановки или возобновления. Организация сохраняет полномочия по решениям в рабочих системах, коммуникации с клиентами и устранению проблем.

Вы получаете каждый подтверждённый путь с воспроизводимыми доказательствами, оценкой серьёзности, рекомендациями и повторной проверкой согласованных исправлений.

Итоговая запись связывает каждую находку с доказательствами, последствиями, ответственным, планом устранения и условиями повторной проверки. По завершении временные тестовые учётные записи и полномочия удаляются, а доказательства хранятся только в течение согласованного срока.

Результаты и порядок повторной проверки согласуются для каждого проекта.

Нет. Оценка проводится методично, опирается на доказательства и отражает конкретный момент времени: выводы относятся к проверенным системам, версиям, конфигурациям и допущениям о доступе.

Систематическая работа по согласованной поверхности не гарантирует обнаружения каждой слабости или пути атаки, как и успешного проникновения тестировщиков. Мы изучаем возможные пути и документируем подтверждённые сценарии эксплуатации уязвимостей с воспроизводимыми доказательствами.

Пентест не гарантирует предотвращения атак и не доказывает, что остановил бы конкретный инцидент прошлого.

Начните с трёх вопросов: Какие системы перемещают средства? Какие доказательства безопасности уже существуют? Какая цепочка контроля ещё не проверялась с позиции атакующего? Ответы выявят пробел в подтверждении безопасности без преждевременного выбора услуги по названию.

Затем на обсуждении объёма согласуются цель, допущения о доступе, защита рабочих систем и ожидаемые результаты.

BlockSec не публикует фиксированные цены; объём, сроки, результаты и индивидуальное предложение предоставляются по запросу после технического обследования.