Я начал(а) обращать больше внимания на то, как проекты блокчейна говорят о безопасности.
Длинный список багов может звучать впечатляюще на бумаге, но само число мне не говорит о многом.
Более интересным в работе Dusk по безопасности AEGIS оказалось то, что происходило под цифрами.
Аудит выдал 39 замечаний, включая 7, классифицированных как критические. Но Dusk сгруппировал эти критические проблемы по четырём базовым причинам, а не рассматривал каждое замечание как отдельную, не связанную друг с другом проблему.
Это различие важно.
Если пять разных проблем возникают из одного и того же допущения, то исправление пяти симптомов не обязательно делает систему в пять раз безопаснее.
Один из примеров — кластер платежных/возвратных сборов Phoenix. Слабое место в том, как информация о комиссиях связывалась между генерацией доказательств, подписью и выполнением, создало несколько возможных исходов, включая перенаправление возврата, инфляцию предложения и даже потенциальную остановку цепочки.
Вот та часть инженерии безопасности, которую, как мне кажется, легко недооценить.
Важный вопрос — не только «Сколько уязвимостей было исправлено?»
Важно другое: «Какое допущение позволило им существовать в первую очередь?»
Для финансовой инфраструктуры это различие становится ещё более значимым. Патч может закрыть путь атаки уже сегодня. Устранение лежащего в основе ошибочного допущения может предотвратить целое семейство проблем завтра.
Возможно, сильный процесс безопасности измеряется не тем, сколько багов есть у системы.
Возможно, он измеряется тем, насколько глубоко команда понимает, почему эти баги вообще были возможны.
#dusk $DUSK @Dusk
Длинный список багов может звучать впечатляюще на бумаге, но само число мне не говорит о многом.
Более интересным в работе Dusk по безопасности AEGIS оказалось то, что происходило под цифрами.
Аудит выдал 39 замечаний, включая 7, классифицированных как критические. Но Dusk сгруппировал эти критические проблемы по четырём базовым причинам, а не рассматривал каждое замечание как отдельную, не связанную друг с другом проблему.
Это различие важно.
Если пять разных проблем возникают из одного и того же допущения, то исправление пяти симптомов не обязательно делает систему в пять раз безопаснее.
Один из примеров — кластер платежных/возвратных сборов Phoenix. Слабое место в том, как информация о комиссиях связывалась между генерацией доказательств, подписью и выполнением, создало несколько возможных исходов, включая перенаправление возврата, инфляцию предложения и даже потенциальную остановку цепочки.
Вот та часть инженерии безопасности, которую, как мне кажется, легко недооценить.
Важный вопрос — не только «Сколько уязвимостей было исправлено?»
Важно другое: «Какое допущение позволило им существовать в первую очередь?»
Для финансовой инфраструктуры это различие становится ещё более значимым. Патч может закрыть путь атаки уже сегодня. Устранение лежащего в основе ошибочного допущения может предотвратить целое семейство проблем завтра.
Возможно, сильный процесс безопасности измеряется не тем, сколько багов есть у системы.
Возможно, он измеряется тем, насколько глубоко команда понимает, почему эти баги вообще были возможны.
#dusk $DUSK @Dusk
