Почему находки низкой степени серьезности говорят больше о вашем аудите, чем критические ошибки Многие аудиторские фирмы сосредотачивают свои продажи на количестве найденных критических ошибок, как будто это число не является просто шумом без учета контекста: предыдущие аудиты, рецензирование коллег, уровни покрытия тестами, сложность кода, количество строк и многие другие метрики. Это самая низкая форма продаж, не отличающаяся от сравнения, например, качества USB-накопителей по их длине в миллиметрах. Чтобы показать альтернативу, мы сначала должны подтвердить правильность нескольких поддерживающих утверждений: - Вероятность случайного внедрения ошибки не имеет предвзятости в сторону более высоких последствий (разработчики не более безрассудны в коде с высокими ставками, обычно наоборот). - Те же самые комплексные методологии, используемые для обнаружения недостатков различной степени серьезности, также обнаружат проблемы высокой серьезности (обратное не верно). - Существуют гораздо более высокие требования для случайной ошибки, чтобы она квалифицировалась как высокая серьезность (часто она будет заблокирована недоступными условиями или затрагивать некритическую функциональность). - Из базовой статистики: более высокая частота выборки коррелирует с меньшим ожидаемым отклонением/вариацией и, следовательно, более точным измерением. Определим отчет об аудите как результат выборки качества кодовой базы. Мы делаем вывод, что ожидаемое истинное (без пропусков) количество критических ошибок значительно ниже, чем низких, и ожидаемое отклонение вокруг него значительно выше (из-за меньшей выборки). Другими словами, количество критических ошибок говорит нам очень мало о количестве пропущенных критических ошибок. Таким образом, удивительно, что отчет с 1 критической и 10 низкими ошибками более обнадеживающий, чем отчет с 10 критическими и 1 низкой ошибкой при прочих равных условиях. Хотя на самом деле подавляющее большинство продавцов предпочли бы показать последнее как показатель качества. Суть в том, что метрика с высокой частотой является лучшим инструментом для измерения результатов с низкой частотой. Создатели Web3, в следующий раз, когда фирмы будут показывать вам свои подсчеты критических/высоких ошибок и X миллиардов долларов, обеспеченных линией, вы знаете, на что сосредоточиться, чтобы найти истинный сигнал. Аудиторы Web3, признайте, что нет последовательной секретной формулы для нахождения всех критических ошибок без также поиска низких - каждая низкая ошибка, не полностью исследованная, является потенциальной критической - и уделяйте максимальное внимание каждой отдельной строке. Ваш клиент поблагодарит вас за это. Низкая степень серьезности определяется как конкретные ошибки в коде, которые не приводят к более высоким уровням воздействия. Не включает форматирование, лучшие практики и несущественные находки.

Вчера была выпущена критическая уязвимость в git, которую можно активировать при git clone ненадежного репозитория. Это идеальный вектор для взлома аудиторов и кражи их вознаграждений / денег за аудит. Обновите свои системы, прежде чем заключать новые контракты! И ожидайте посетителей в вашем почтовом ящике в ближайшие недели...

Оказывается, вы можете заработать 5-значные вознаграждения на конкурсах, не обнаруживая никаких проблем, просто нужно полусоображающее сознание. На конкурсе OP Fault Proofs в марте 2024 года разработчики исправили критическую проблему за день до его начала, но не объединили её. 🔗 Просто взглянув на публичный журнал коммитов, вы получаете высокую награду 🔗 🔗 В итоге это оказалось вознаграждением в $16680: Это всего лишь один из многих трюков, чтобы найти ошибки в рамках без фактического их поиска. Всегда старайтесь работать умно, а не усердно.

Решил попробовать Cantina в прошлом октябре, 8 месяцев спустя результаты наконец-то вышли... Десятки индивидуальных находок в первом аудите Java и превосходство над топовыми участниками таблицы лидеров Cantina в 3-7 раз ощущается довольно хорошо, не буду лукавить. Жаль, что опыт после аудита был таким ужасным, что я поклялся никогда не возвращаться на эту платформу. *предупреждение о оправданной тираде* - Время разрешения 8 месяцев, на момент написания - вознаграждение все еще не отправлено. - Десятки часов потрачено на эскалацию и защиту заявок от неверных решений. - Подсчитано ~ 104 ошибки судейства (неправильные дубликаты, явные недействительные, неверная степень серьезности), которые были исправлены. Больше, которые не были. - Убыток в стоимости ~$110,000 из-за того, что разрешение заняло на 7 месяцев больше, чем должно, и токен OP обвалился до ~50 центов. Конечно, когда участвуешь в конкурсах с призовыми фондами не в USD, колебания - это принятый риск. Но 8 месяцев некомпетентности судей и неспособности завершить конкурс не входило в мою модель угроз. Во время судейства C4 я полностью обрабатывал 1000 находок менее чем за неделю (в одиночку), у OP-Java было 360 и несколько судей. Неудивительно, что Cantina никогда не объявляла результаты в социальных сетях, в отличие от 5 других конкурсов, которые завершились на этой неделе, конечно, не могло быть так, что они хотели избежать плохой прессы или подчеркнуть доминирование TrustSec, верно? Жаль, что нам приходится продолжать обсуждать злоупотребления платформы вознаграждений вместо критических ошибок, но нет другого выбора, кроме как держать всех под отчетом. Скоро выйдет пост с техническим разбором без тирад для индивидуальных находок.

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

Каждый день становится все более очевидным, что @cantinaxyz является экстрактивной сущностью и представляет собой чистый негатив для пространства. Прошла неделя с момента публикации убийственной статьи @jack__sanford о бесчисленных недостатках конкурса Cork, и пока нет никаких намеков на ответ. Учитывая количество внимания, которое получила эта статья, если бы они могли защититься, они бы, безусловно, это сделали, то есть молчание — это признание вины. На этой неделе наша подача вознаграждения Cantina, которую они согласились показать как ограниченные потери средств для оператора блокчейна с высокой вероятностью, разрешилась в медиации с низкой степенью серьезности. Прочитав десятки отчетов Spearbit/Cantina и сотни описаний вознаграждений, денежные потери любого размера никогда не бывают ниже средней степени воздействия, поэтому они явно передают точку зрения спонсора в классическом менталитете "клиент всегда прав", как они всегда и делают. На самом деле, они даже не скрывают этого. По их собственным документам, они по умолчанию принимают точку зрения клиента. Я полагаю, только в самых вопиющих случаях они отвергают мнение клиента. А что если клиент просто игнорирует их медиацию? На любой другой платформе (например, @immunefi), с которой мы работали, неуважение к медиации является основанием для немедленного удаления клиента. На Cantina клиенту разрешено 5 мошенничеств с вознаграждениями в год. Да, вы правильно прочитали. Мы также недавно обнаружили, что их программа Fellowship имеет крайне агрессивный пункт о эксклюзивности. Участники не могут подавать ничего на другие платформы вознаграждений или уведомлять проекты напрямую, даже если под угрозой находятся миллионы долларов. Вместо этого эта высокочувствительная и критически важная информация должна быть передана Cantina, которая решает, как действовать. Они босс, они принимают решения, подчиняйтесь или уходите. У нас есть больше примеров возмутительного обращения с Cantina, но мы оставим их на другой день. На данный момент мы хотим повысить осведомленность, как и другие ведущие члены сообщества, что аудиторы должны голосовать ногами, когда дело касается того, где они тратят свое драгоценное время на охоту. Платформа безопасности, которая теряет баланс и ставит проекты выше охотников за вознаграждениями, подрывает весь процесс "белых шляп" и побуждает исследователей зарабатывать свою стоимость менее этичными способами! Давайте работать как сообщество, чтобы укрепить организации с высокой целостностью, прозрачностью и чистым положительным воздействием, а не индустриальных хулиганов. Вышеуказанное заявление является личным мнением членов руководства TrustSec и должно интерпретироваться как таковое.

- Держите изменяющий состояние код (LoC) ниже 500 - используйте паттерн ++counter для сопоставления ключей - не поддерживайте нативные токены - держите машину состояний в открытом виде через перечисления состояний - соотношение тестов к LoC 1:1 - форматируйте каждую строку кода с помощью линейки Смотрите, выиграть в игре не так уж и сложно

Как ветеран индустрии аудиторских конкурсов, я расскажу вам, как заключаются такие сделки. > Будьте протокольны с деньгами и проводите 3+ совместных аудита > Знайте, что в кодовой базе, вероятно, нет значительных ошибок > Хотите сигнализировать сообществу, инвесторам и другим заинтересованным сторонам, что вы заботитесь о безопасности > Не намерены тратить больше денег на безопасность > Платформа "Конкурс" имеет решение > Устройте конкурс на "rug", гарантируя, что High/Crit призы не будут разблокированы > Сделайте Med приз очень маленьким > Если найден High, то приуменьшайте значимость, иначе клиент будет недоволен (помните Euler?) > И платформа "Конкурс", и вы получаете бесплатный маркетинг > SRs обмануты, но вам все равно > Повторите, но сделайте следующее объявление о конкурсе на "rug" еще более оптимистичным.

Предупреждение ⚠️: Это не новый отчет о баунти Мы, аудиторы, все любим сосредотачиваться на сочных критических уязвимостях и сводить к минимуму нетехническую работу. Кому нужны бумажная волокита и встречи, когда вы только что нашли новый способ опустошить DeFi-контракт? Но все должно быть в меру, и слишком часто мы видим, как независимые исследователи полностью пренебрегают даже базовым соглашением с клиентом. Это было то, что мы тоже делали в первые месяцы работы TrustSec — связывались с клиентом в TG/Discord, обсуждали команду, цену и сроки, и просто начинали. Казалось, что все идет гладко и без трений, так в чем же проблема? Как и во многих вещах, это работает хорошо, пока не перестает. Когда вы проводите более 50 аудитов в год, вы начинаете сталкиваться с крайними случаями. И когда это происходит, наличие заранее оговоренных условий позволяет избежать множества трений в потенциально чувствительные моменты аудита. Смотрите, цель соглашения об услугах не в том, чтобы его можно было оспорить в суде за тысячи миль от вашего текущего местоположения. Конечно, в худшем случае это возможно. Но в основном оно нужно для согласования ожиданий обеих сторон, способа заставить обе стороны обсудить детали, которые они иначе не затронули бы. Вот лишь несколько сценариев, которые возникали и которые следует явно предусмотреть: - Клиент не готов с финальной версией к началу аудита. - По непредвиденным причинам один или несколько аудиторов недоступны на часть или весь период аудита. - Финальный объем работы требует большего времени на проверку, что увеличивает затраты. - Споры о том, какой инструмент и формат использовать для подсчета итогового SLOC. - Клиент добавляет новую функциональность для проверки в процессе исправления. - Запрос на оплату только после доставки отчета. - Клиент хочет отменить аудит за 24 часа до начала. - Клиент хочет отправить оплату в своей предпочитаемой блокчейн-сети. - Возражения против публикации отчета после приемлемого периода ожидания. Помимо того, что соглашение проясняет, как справляться с этими сценариями, оно также предоставляет аудиторам критически важную защиту: - Освобождает от ответственности за пропущенные баги и эксплойты. - Сохраняет права интеллектуальной собственности на инструменты и концепции атак, разработанные во время аудита (в пределах, разрешенных законом). - Устанавливает предоплаты, штрафы за отмену и так далее. - Соответствует требованиям должной осмотрительности, KYB и правовой базы. Это важно для налогообложения, соблюдения норм и требований к источнику средств. По этим причинам мы быстро поняли, что потратить немного дополнительного времени перед началом работы стоит того, и мы призываем каждого аудитора, ведущего легитимный бизнес, делать то же самое.

В конце 2024 года TrustSec обнаружила ошибку консенсуса в клиенте Optimism от @OPLabsPBC. В худшем случае op-node будет иметь неправильное представление о состоянии L2, что приведет к разделению цепочки от других клиентов. За наше исследование OP Labs щедро наградили нас премией в размере $7,5 тыс. Ознакомьтесь со всеми подробностями в техническом отчете ниже!