Про подготовку к аудиту

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

Пару дней назад начался конкурс для протокола SecondSwap. Это единственный конкурс на моей памяти, который переносился 4 раза! Изначально он должен был запуститься 24 ноября, потом его перенесли на 29, потом на 5 декабря, потом на 9!

Мне были очень интересны причины этого. И после старта они стали понятны. Подготовка к конкурсу просто ужасная. Пошли по порядку:

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

Да, аудитору, в целом, достаточно кода для хорошей проверки. При этом с подробной документацией он может сравнить "задумку" разработчиков с фактической реализацией, найти несоответствия или подсказать лучшие паттерны. Довольно часто в отчетах я встречал High/Med баги с ссылкой на формулировки в документации протокола.

2. Протокол заказывал аудит в другой компании, но к его началу аудиторам не показали отчет. Многие вышли из конкурса, так как по правилам все находки, даже acknowledged, уже не валидны для данного конкурса. Т.е. аудитор мог подать репорт, не зная, что в отчете уже описан этот баг и его бы не засчитали. Другими словами, это просто потраченное время для аудитора с нулем пользы для протокола.

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

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

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

4. Связь с командой. В первые дни команда вообще не появлялась в чате. Все вопросы аудиторов игнорировались. И только со вчерашнего вечера пошли первые отчеты. Это тоже в корне не правильный подход.

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

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

Вот есть отличный гайд о подготовке протокола к аудиту:

https://auditprofile.xyz/plan.php

Если хотите нанять аудитора, то убедитесь, что соответствуете требованиям.

#audit