Я переставил заново эти 12 строк из официального аудиторского индекса Dusk: сначала сгруппировал по компонентам, затем приклеил рядом даты. Когда таблица была готова, та фраза, которая раньше звучала так гладко — «Dusk уже был(а) проаудирован(а)» — вдруг уже не получалось написать дословно: у каждого отчёта есть свои объекты и своё время, и ни одна строка не называется «текущий полный сертификат всего стека кода».
Две самые последние позиции — это оценки безопасности ERC20 и BEP20 на апрель 2026 года. Основные же отчёты по ключевому протоколу, консенсусу, узлам, Phoenix и т.п. в основном приходятся на 2023—2024 годы. Здесь дело не в том, что «старое/новое важнее», а в том, что отчёт может говорить только о тех компонентах, которые он действительно проверял. Добавленные позже модули и версии с существенными изменениями нельзя, опираясь лишь на одинаковость названий проекта, унаследовать выводы из старых отчётов.
Эта таблица реально изменила мои действия по проверке. Теперь, когда вижу рекламные материалы о безопасности, я не буду сначала спорить «есть ли польза от аудита», а сначала потребую четыре вещи: название отчёта, проверяемый компонент, дату аудита и соответствующую версию. Только если все четыре совпадают, тогда продолжаю читать находки и квитанции о исправлениях; если дать лишь логотип проекта или логотип аудиторской организации — информация всё равно остаётся на уровне рекламы.
Для $DUSK такие ограничения вовсе не означают сознательного спора «в противовес». То, что аудиторский репозиторий открыт, а отчёты можно отследить, само по себе — хорошая вещь; если точно обозначить границы, станет видно, где уже есть подтверждённые доказательства, а где из‑за смены версии нужно предоставить дополнительные. Старые отчёты тоже не следует произвольно считать недействительными — просто они не могут автоматически гарантировать те объекты, которые не были охвачены.
Ещё две вещи нельзя вывести из этих 12 строк. На этот раз я не оцениваю качество каждого отчёта и не проверяю по пунктам, что проблемы во всём объёме действительно полностью исправлены; если в открытом индексе не указана какая‑то конкретная работа, это не доказывает, что в другом месте её абсолютно нет. Индекс, предоставленный @Dusk , подходит как точка входа, а не как финальная точка выводов.
Фраза «проаудировано» экономит много слов, но вместе с тем убирает и самые важные границы. Когда я разложил эти 12 строк по полочкам, безопасностная оценка наконец получила отслеживаемого подлежащего, а также время и версию. В следующий раз, когда кто‑то будет использовать выводы, сделанные по всему проекту целиком, я попрошу его сначала указать, о какой именно строке идёт речь. #dusk
Две самые последние позиции — это оценки безопасности ERC20 и BEP20 на апрель 2026 года. Основные же отчёты по ключевому протоколу, консенсусу, узлам, Phoenix и т.п. в основном приходятся на 2023—2024 годы. Здесь дело не в том, что «старое/новое важнее», а в том, что отчёт может говорить только о тех компонентах, которые он действительно проверял. Добавленные позже модули и версии с существенными изменениями нельзя, опираясь лишь на одинаковость названий проекта, унаследовать выводы из старых отчётов.
Эта таблица реально изменила мои действия по проверке. Теперь, когда вижу рекламные материалы о безопасности, я не буду сначала спорить «есть ли польза от аудита», а сначала потребую четыре вещи: название отчёта, проверяемый компонент, дату аудита и соответствующую версию. Только если все четыре совпадают, тогда продолжаю читать находки и квитанции о исправлениях; если дать лишь логотип проекта или логотип аудиторской организации — информация всё равно остаётся на уровне рекламы.
Для $DUSK такие ограничения вовсе не означают сознательного спора «в противовес». То, что аудиторский репозиторий открыт, а отчёты можно отследить, само по себе — хорошая вещь; если точно обозначить границы, станет видно, где уже есть подтверждённые доказательства, а где из‑за смены версии нужно предоставить дополнительные. Старые отчёты тоже не следует произвольно считать недействительными — просто они не могут автоматически гарантировать те объекты, которые не были охвачены.
Ещё две вещи нельзя вывести из этих 12 строк. На этот раз я не оцениваю качество каждого отчёта и не проверяю по пунктам, что проблемы во всём объёме действительно полностью исправлены; если в открытом индексе не указана какая‑то конкретная работа, это не доказывает, что в другом месте её абсолютно нет. Индекс, предоставленный @Dusk , подходит как точка входа, а не как финальная точка выводов.
Фраза «проаудировано» экономит много слов, но вместе с тем убирает и самые важные границы. Когда я разложил эти 12 строк по полочкам, безопасностная оценка наконец получила отслеживаемого подлежащего, а также время и версию. В следующий раз, когда кто‑то будет использовать выводы, сделанные по всему проекту целиком, я попрошу его сначала указать, о какой именно строке идёт речь. #dusk