Dusk поставила 39 исправлений через AEGIS. Среди результатов, которые легли в основу этой ремедиации, 7 были оценены как критические. Звучит как большое количество отдельных проблем безопасности. Но эти 7 критических находок свелись всего к 4 первопричинам — поэтому итоговое количество в заголовке менее однозначно, чем кажется на первый взгляд.
Тридцать девять исправлений говорят мне о масштабе работы Dusk по ремедиации. Но они не говорят о том, сколько независимых сценариев отказа эти исправления фактически устраняли. Чего я пока не знаю, так это того, стабильно ли процесс ремедиации Dusk последовательно устраняет общие причины сразу у нескольких находок, а не просто закрывает отдельные пути эксплуатации, которые в итоге всплыли.
Собственный процесс AEGIS от Dusk дает один полезный механизм, за которым можно следить. Критическая ремедиация отслеживается не только по закрытию эксплойтов, но и по закрытию первопричин, а также по наличию регрессионного покрытия. Поэтому для меня будущая повторяемость ценнее, чем просто “сырой” подсчет количества исправлений. Публикация патча доказывает, что известная проблема была устранена. Более сильным доказательством было бы видеть, что тот же класс лежащих в основе отказов перестает повторно всплывать в последующих обзорах или в соседних компонентах стека.
Поскольку Dusk развивает инфраструктуру для нативных сценариев выпуска, где большая часть жизненного цикла регулируемой безопасности может зависеть напрямую от базовой сети, ремедиация по первопричинам становится более значимым сигналом безопасности, чем просто “количество отправленных исправлений”.
Мне было бы проще и больше узнать из доказательств того, что несколько общих первопричин были полностью устранены, чем из более крупного числа исправлений, не зная, сколько независимых сценариев отказа стояло за этим.
Вопрос в том, сокращает ли процесс безопасности Dusk именно лежащие в основе классы отказов, а не только число открытых находок. Я наблюдаю, появляются ли те же первопричины снова в более поздних аудитах, как развивается регрессионное покрытие и не проявляются ли где-то еще в стеке похожие предположения низкого уровня.
#dusk $DUSK @Dusk ✨
Тридцать девять исправлений говорят мне о масштабе работы Dusk по ремедиации. Но они не говорят о том, сколько независимых сценариев отказа эти исправления фактически устраняли. Чего я пока не знаю, так это того, стабильно ли процесс ремедиации Dusk последовательно устраняет общие причины сразу у нескольких находок, а не просто закрывает отдельные пути эксплуатации, которые в итоге всплыли.
Собственный процесс AEGIS от Dusk дает один полезный механизм, за которым можно следить. Критическая ремедиация отслеживается не только по закрытию эксплойтов, но и по закрытию первопричин, а также по наличию регрессионного покрытия. Поэтому для меня будущая повторяемость ценнее, чем просто “сырой” подсчет количества исправлений. Публикация патча доказывает, что известная проблема была устранена. Более сильным доказательством было бы видеть, что тот же класс лежащих в основе отказов перестает повторно всплывать в последующих обзорах или в соседних компонентах стека.
Поскольку Dusk развивает инфраструктуру для нативных сценариев выпуска, где большая часть жизненного цикла регулируемой безопасности может зависеть напрямую от базовой сети, ремедиация по первопричинам становится более значимым сигналом безопасности, чем просто “количество отправленных исправлений”.
Мне было бы проще и больше узнать из доказательств того, что несколько общих первопричин были полностью устранены, чем из более крупного числа исправлений, не зная, сколько независимых сценариев отказа стояло за этим.
Вопрос в том, сокращает ли процесс безопасности Dusk именно лежащие в основе классы отказов, а не только число открытых находок. Я наблюдаю, появляются ли те же первопричины снова в более поздних аудитах, как развивается регрессионное покрытие и не проявляются ли где-то еще в стеке похожие предположения низкого уровня.
#dusk $DUSK @Dusk ✨