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

Разберу структуру отчёта, что означают уровни критичности и на какие места смотреть в первую очередь.

Что аудит проверяет

Начну с границ, потому что их обычно не проговаривают.

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

Дальше начинаются границы.

Аудит не оценивает экономику проекта, не проверяет честность команды и не отвечает за то, что произойдёт с кодом после публикации отчёта.

Структура отчёта

Документы разных аудиторов похожи по составу.

Первая и последняя строки важнее середины.

Объём работ говорит, что именно проверено, а оговорки — чего проверка не касалась вовсе, и обе эти вещи определяют ценность документа.

Уровни критичности и их инфляция

Здесь скрыт главный подвох.

Уровни идут от низкого к критическому, и логика простая: чем выше отметка, тем серьёзнее последствия при использовании уязвимости и тем меньше времени остаётся на реакцию.

Назначает их сам аудитор.

Иногда уровень угрозы сознательно завышают: малозначительные замечания отмечают как высокие, чтобы отчёт выглядел серьёзнее, а проделанная работа — основательнее.

Для читателя это создаёт иллюзию.

Много «высоких» находок кажется признаком тщательной проверки, тогда как реальных рисков там может почти не быть.

Как отличить содержательную находку

Смотреть надо не на ярлык, а на обоснование.

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

Чем конкретнее, тем лучше.

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

Обратное тоже верно, и об этом стоит помнить при первом взгляде на сводку находок.

Множество критических отметок без технических подробностей — повод усомниться в качестве работы аудитора, а не в качестве проверенного кода.

Статус исправлений

Раздел, ради которого отчёт и читают.

Находка сама по себе ещё не проблема.

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

1. Исправлено. Код изменён, аудитор проверил повторно.
2. Принято к сведению. Команда согласна, но менять не стала.
3. Отклонено. Команда не считает это проблемой.

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

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

Где искать сам отчёт

Документ должен быть публичным.

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

Начните с сайта аудитора.

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

Проверьте дату публикации.

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

Дата и версия

Параметр, который обесценивает документ чаще всего.

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

Сверяйте с адресом контракта.

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

Смотрите и на возраст документа.

Аудит трёхлетней давности при активно развивающемся проекте говорит о прошлом состоянии дел, а вовсе не о нынешнем.

Проверка контракта своими силами

Часть работы аудитора доступна любому желающему, и занимает она минуты.

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

Дальше смотрите на права владельца.

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

Ищите скрытые условия.

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

Порядок проверки адреса перед подключением описан в материале о том, как проверить ссылку перед подключением кошелька.

Кто проводил проверку

Имя аудитора значит больше, чем кажется.

На рынке есть компании с многолетней историей и публичными отчётами, а есть фирмы, о которых известно только из самого отчёта.

Проверьте, существует ли аудитор.

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

И проверьте наличие отчёта у самого аудитора.

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

Один аудит или несколько

Число проверок само по себе ничего не решает, но кое-что показывает.

Несколько независимых аудитов лучше одного.

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

Но смотреть надо на независимость.

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

И на разнесение во времени.

Проверка перед запуском и повторная после крупного обновления — это разумная практика, а два отчёта одной даты обычно означают формальность.

Программы поиска уязвимостей

Дополнение к аудиту, о котором стоит знать.

Часть проектов объявляет вознаграждение за найденные ошибки, приглашая независимых исследователей проверять код постоянно, а не разово.

Это работает иначе, чем аудит.

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

Обратите внимание на размер вознаграждения.

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

Права владельца контракта

То, что аудит отмечает, но не считает уязвимостью.

Многие контракты позволяют владельцу менять параметры: комиссии, лимиты, права доступа, а иногда и возможность остановить операции или изъять средства.

Формально это не ошибка.

Функция работает как задумано, и аудитор отмечает её как особенность, а не как уязвимость — но для вас риск от этого меньше не становится.

Читайте такие разделы особенно внимательно.

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

Чего аудит не покрывает

Перечислю прямо, потому что этого ждут от документа напрасно.

Экономическая модель вне его охвата.

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

Внешние зависимости тоже не проверяются.

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

И полной гарантии он не даёт.

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

Аудит и выданные разрешения

Связь, о которой вспоминают редко.

Подключаясь к приложению, вы выдаёте его контракту право распоряжаться своими токенами, и качество этого контракта определяет судьбу выданного доступа.

Отсюда практический порядок.

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

И помните про срок жизни доступа.

Разрешение переживает и обновление контракта, и потерю интереса к проекту, поэтому ревизия нужна независимо от результатов аудита; порядок описан в материале о том, как проводить ежеквартальную ревизию выданных разрешений.

Что делать после чтения

Отчёт прочитан — остаётся принять решение.

Сопоставьте находки с суммой вложения.

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

Проверьте свежесть и совпадение версий.

Работающий контракт должен соответствовать проверенному, иначе документ теряет практический смысл.

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