Bitcoin Core пересмотрел подход к публикации исправлений безопасности для ошибок, которые можно быстро обнаружить повторно, в том числе с помощью простого запроса к языковой модели. Новая политика вводит отдельную категорию «Легко обнаруживаемые» и позволяет выпускать точечные обновления с публичным уведомлением как можно быстрее, не дожидаясь стандартного годичного эмбарго для уязвимостей средней и высокой степени серьезности.
Изменение в политику раскрытия уязвимостей было объединено 22 октября. В тот же день участник Bitcoin Core из Chaincode Labs Антуан Пуансот сообщил о нем в списке рассылки Bitcoin Development. По его словам, сопровождающие проекта все чаще получают отчеты о проблемах безопасности, которые легко найти заново, потому что современные ИИ-модели резко снизили порог входа для поиска отдельных классов ошибок и анализа скрытых исправлений.
«Недавно мы зафиксировали рост числа сообщений об уязвимостях безопасности, которые можно легко обнаружить или повторно обнаружить. Во многом это связано с тем, что ИИ-модели заметно упрощают выявление определенных типов проблем или поиск скрытых исправлений», — написал Антуан Пуансот.
Почему прежняя модель с долгим эмбарго перестала работать для части ошибок
Раньше сроки раскрытия в Bitcoin Core зависели от уровня серьезности уязвимости. Ошибки низкой степени серьезности публиковались через две недели после выхода следующего основного релиза. Для уязвимостей средней и высокой степени серьезности детали оставались закрытыми до двух недель после завершения поддержки последнего затронутого выпуска. На практике сама политика описывала этот период как примерно один год после первого основного релиза, в котором появлялось исправление.
Такой осторожный график появился не случайно. Bitcoin Core остается эталонной реализацией, на которой работает большинство нод Bitcoin, а операторы нод часто обновляют программное обеспечение медленно и осознанно. Долгое эмбарго давало сети время установить исправления до того, как детали проблемы станут публичными.
У этой модели была и обратная сторона: исправления безопасности обычно не переносились в старые ветки. Если оператор продолжал использовать более раннюю версию, ему приходилось ждать следующего основного релиза. Проект стремится выпускать такие релизы примерно раз в шесть месяцев.
Пуансот подчеркнул, что это не случайная особенность, а следствие устройства проекта и культуры обновлений. По той же причине изменения уровня консенсуса, включая апгрейд Taproot, проходят медленно и консервативно: операторы должны иметь возможность внедрять их в своем темпе.
«Из-за природы нашего проекта и культуры медленных обновлений наша политика безопасности отдавала предпочтение более длительному эмбарго. Обычно это означает, что исправления безопасности не могут быть перенесены назад и становятся доступны пользователям только со следующим основным релизом», — отметил Пуансот.
Проблема в том, что ИИ меняет баланс рисков. Если уязвимость можно повторно обнаружить простым автоматизированным поиском или запросом к чат-боту, ее сокрытие уже почти не защищает сеть. Зато задержка с выпуском исправленной версии продолжает мешать пользователям быстро закрыть риск.
Как работает новая категория «Легко обнаруживаемые»
В обновленной политике появился третий сценарий раскрытия. На этапе классификации уязвимость может получить статус «Легко обнаруживаемая». Под этим понимается проблема, которую можно выявить с минимальными усилиями, например при помощи простого запроса к ИИ.
Важно, что категория не привязана только к ошибкам, изначально найденным искусственным интеллектом. Ключевой критерий — не инструмент, а легкость повторного обнаружения. Если проблему дешево и просто найти заново, она может попасть в новый режим раскрытия.
Для таких случаев меняется сам порядок реакции. Вместо того чтобы включить исправление только в следующий крупный релиз, сопровождающие будут переносить патч во все поддерживаемые основные версии. По правилу Bitcoin Core это последние три релиза. После этого проект должен выпустить точечные обновления как можно скорее, а уведомление о безопасности публикуется одновременно с исправленным программным обеспечением.
Остальная шкала серьезности сохраняется. Уязвимости низкой степени по-прежнему раскрываются по двухнедельному графику. Ошибки средней и высокой степени серьезности остаются в примерно годовом цикле, если они не признаны легко обнаруживаемыми. Критические уязвимости, способные привести к краже монет на уровне протокола, увеличению предложения или необратимому расколу цепи, как и раньше, выводятся за рамки стандартной процедуры и рассматриваются отдельно.
Именно к такому критическому уровню относился инфляционный баг CVE-2018-17144, обнаруженный в сентябре 2018 года. Он мог позволить создавать монеты вне установленного графика эмиссии. Новый ускоренный режим не предназначен для подобных случаев: при угрозе такого масштаба реакция все равно будет индивидуальной и ориентированной на риск для всей сети.
Что меняется на практике: две недели, год или «как можно скорее»
Проще всего понять новую политику через сроки. Обычная уязвимость средней степени серьезности, исправленная сегодня, при старом подходе могла оставаться непубличной около 52 недель и раскрывалась только после того, как последний затронутый релиз выходил из поддержки. Если такая же ошибка будет признана легко обнаруживаемой, патч выйдет в виде точечного релиза вместе с уведомлением как можно быстрее.
Разница заключается не только в раскрытии деталей. Теперь исправление должно попасть в старые, но все еще поддерживаемые ветки. Это дает оператору ноды возможность установить узкий патч безопасности, не переходя сразу на самый свежий основной релиз со всеми его новыми функциями и изменениями поведения.
Для сети, где обновления часто внедряются неторопливо, это важное изменение. Исправление может быстрее дойти до тех, кто не готов или не хочет немедленно переходить на новую основную версию Bitcoin Core.
У ускоренного подхода есть свои риски
Пуансот отдельно указал на компромисс: чем быстрее выпускается исправление, тем меньше времени оно проводит в разработческих ветках до попадания к пользователям. Патч, подготовленный за дни, проходит более короткий цикл проверки и тестирования, чем исправление, которое месяцами «выдерживается» в процессе разработки.
«Это особенно важно, поскольку при такой политике исправления будут иметь меньше времени на выдержку в ветках разработки перед выпуском пользователям», — написал Пуансот в запросе на слияние.
Обсуждение также затронуло момент публикации информации. Часть участников считала, что сам факт открытия запроса на слияние с исправлением может подсказать злоумышленникам направление поиска: автоматическое отслеживание репозитория стоит дешево. Поэтому раскрытие, по их мнению, может потребоваться не позднее применения патча, а иногда и раньше — вместе с рекомендациями по снижению риска.
Другой участник предлагал выпускать исправления с отложенным или выборочным уведомлением. Пуансот отверг такой вариант. По его позиции, предупреждение без конкретных деталей может вызвать поспешную миграцию среди операторов, которым на самом деле ничего не угрожало.
Итоговый вариант политики стал компромиссом. Проект сохраняет привязку уведомления к готовому исправлению и публикует полноценную информацию, а не ограничивается расплывчатым предупреждением.
Когда новая политика пройдет первый реальный тест
Пока ни одна уязвимость не была добавлена в новый класс. Речь идет о смене процесса, а не о раскрытии активной ошибки. Первый практический тест наступит тогда, когда сопровождающие Bitcoin Core во время классификации признают конкретную проблему легко обнаруживаемой и выпустят точечные обновления для всех поддерживаемых веток одновременно с уведомлением.
Сам факт изменения политики показывает, что поиск ошибок с помощью ИИ уже влияет на инфраструктуру Bitcoin. Ранее в этом году Core Lightning призвал операторов нод обновиться или отключиться после подтверждения уязвимостей, найденных при помощи ИИ. Теперь похожая логика применяется на уровне эталонной реализации: если повторное обнаружение проблемы стоит дешево, секретность почти не помогает, а длительное эмбарго в основном задерживает доступ к исправлению.
Для операторов нод прямо сейчас ничего не меняется: обычный ритм обновлений остается прежним. Разница станет заметна при следующей уязвимости, которую признают легко обнаруживаемой: патч и уведомление могут выйти быстрее и с меньшим предварительным запасом времени, чем раньше.
Новости о биткоин, блокчейне и криптовалютах
Автор: Сoinspot