«Проект говорит, что инцидент уже обработан, с активами всё в порядке — значит, я могу продолжать держать?»

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

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

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

По-настоящему повышает доверие то, что меры по устранению и причины инцидента один-в-один соотносятся. Если проблема возникла из‑за утечки полномочий, недостаточно просто заменить один ключ — нужно перекрыть, почему полномочия вообще могли быть получены и почему атакующий смог дойти до ключевых операций. Если причина в логике контракта, исправление не должно ограничиваться «запиранием» поверхностных точек входа; когда атака может пройти к одной и той же базовой логике из разных мест, патч должен лечить общую первопричину, и его нужно перепроверить с использованием исходного сценария атаки.

Я также особенно внимательно отслеживаю, когда проект возобновляет обслуживание. Если восстановление происходит быстро, это не обязательно означает, что у команды высокая компетентность; если первопричина не воспроизведена, исправления не перепроверены и старое опасное состояние не мигрировало/не устранено, то слишком ранний перезапуск фактически возвращает пользователей обратно в риск. Более надёжный подход: сначала подтвердить, что путь атаки заблокирован, затем обработать состояние, на которое инцидент повлиял; после внешней верификации или целевых тестов — и в конце восстановить работу поэтапно, фиксируя на каждом шаге результаты, которые можно проверить.

Обычным держателям монет компенсационные договорённости тоже нельзя «размывать» одной фразой «мы будем нести ответственность». Кто относится к затронутым пользователям, по какому моменту времени и по каким записям; откуда будут выплачиваться компенсации; сколько уже сделано и какой именно остаётся недостающий разрыв — всё это должно становиться ясным шаг за шагом. Прогресс в возвращении средств, конечно, хорошо, но вернуть деньги и то, что проект добровольно берёт на себя недостачу, — это разные вещи. Нельзя подменять конкретный план для пользователей формулировкой «идёт расследование».

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

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

Проверка серьёзных заявлений действительно должна решить не задачу «сделать эмоциональный вывод за кого-то», а сверить заявления с фактическими действиями. Безопасность нельзя доказать одной фразой — она подтверждается тем, что атака остановлена, что бухгалтерия сходится, что уязвимости перекрыты, что пользователи получили обработку и после восстановления система продолжает работать нормально; доказательства нужно выстраивать постепенно.

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