Bitcoin Core отказывается от длительных эмбарго на уязвимости, которые ИИ способен найти заново
Ключевые выводы
- •Bitcoin Core в четверг внес изменения в политику безопасности: теперь то, насколько легко уязвимость можно обнаружить заново, а не только степень серьезности, влияет на сроки раскрытия информации.
- •Уязвимости с меткой «легко обнаруживаемая» — в том числе те, что можно выявить простым запросом к LLM, — теперь будут получать перенесенные исправления во все поддерживаемые мажорные версии, а рекомендации публикуются одновременно с исправленным ПО.
- •Изменение предложил разработчик Chaincode Labs Антуан Пуансо, отметив, что большие языковые модели радикально снизили барьер для поиска определенных классов проблем и выявления скрытых исправлений.
- •Критические ошибки, способные привести к краже монет на уровне протокола, увеличению эмиссии или постоянному разделению цепочки, остаются вне стандартного графика и рассматриваются в индивидуальном порядке.
- •Смена политики последовала за месяцами давления с использованием ИИ, включая около 4 962 находок Bitcoin Red Team в 390 репозиториях и эксплуатацию уязвимости BTCPay Server, о которой сообщили конфиденциально, на работающих серверах торговцев.

Bitcoin Core пересмотрел политику раскрытия уязвимостей, чтобы ускорить выпуск исправлений для уязвимостей, которые большие языковые модели способны обнаружить с минимальными усилиями, отказавшись от многомесячных эмбарго, которые ранее распространялись на такие ошибки.
Мейнтейнеры внесли изменение в политику безопасности проекта в четверг. Разработчик Chaincode Labs Антуан Пуансо, автор предложения, анонсировал его в тот же день в сообщении в списке рассылки Bitcoin Development Mailing List.
«Недавно мы столкнулись с ростом числа сообщений об уязвимостях, которые можно легко (повторно) обнаружить», — написал Пуансо. — «Это во многом связано с тем, что LLM радикально снизили порог для поиска определенных классов проблем или выявления скрытых исправлений».
Пересмотр делает обнаруживаемость, а не только степень серьезности, фактором, определяющим, насколько быстро программное обеспечение, на котором работает большинство узлов Bitcoin, получает публичное исправление.
Как политика работала раньше
В рамках прежней схемы Bitcoin Core — программное обеспечение, работающее на большинстве узлов сети Bitcoin — классифицировал каждую сообщенную уязвимость по степени серьезности и соответствующим образом планировал ее раскрытие. Уязвимости низкой степени серьезности становились публичными через две недели после выхода следующей мажорной версии. Проблемы средней и высокой степени серьезности оставались под эмбарго до истечения двух недель с момента окончания жизненного цикла последней затронутой версии — срок мог достигать года.
Длительные сроки были призваны дать операторам узлов, многие из которых обновляются медленно, время перейти на исправленное ПО до того, как детали станут публичными. На практике это означало, что исправления не выпускались для старых поддерживаемых версий и появлялись только со следующей мажорной версией.
Пуансо утверждал, что этот компромисс не работает для уязвимостей, которые легко обнаружить заново. «Период эмбарго почти ничего не дает, но откладывает доступность исправленного релиза», — говорится в политике.
Что меняется
Во время сортировки Bitcoin Core теперь может помечать уязвимость как «легко обнаруживаемую» — категория определяется в политике как проблемы, которые можно найти «с минимальными усилиями, например с помощью простого запроса к LLM». Метка применима и к уязвимостям, найденным другими способами.
Для таких проблем проект будет переносить исправление во все поддерживаемые мажорные версии, выпускать точечные релизы как можно скорее и публиковать рекомендации по безопасности с некоторыми деталями одновременно с исправленным ПО. Пуансо признал, что такие исправления будут иметь меньше времени на тестирование до того, как попадут к пользователям. Для операторов старых поддерживаемых версий это означает, что патчи теперь приходят в виде точечных релизов, а не в ожидании следующей мажорной версии, а детали публикуются в момент выпуска исправления.
Уязвимости вне этой категории сохраняют существующий график, основанный на степени серьезности. Критические ошибки — те, что могут привести к краже монет на уровне протокола, увеличению эмиссии или постоянному разделению цепочки — остаются за рамками стандартной политики и будут рассматриваться в индивидуальном порядке.
Разработчик Антуан Риар предлагал вариант выпустить исправление без рекомендации withholding деталей в индивидуальном порядке. Пуансо отказался, написав, что предупреждение пользователей без деталей «может необоснованно создать больше риска», побуждая к поспешной миграции пользователей, которые иначе не были бы затронуты.
Лето отчетов, созданных ИИ
Смена политики произошла на фоне месяцев возросшего давления на open-source проекты Bitcoin. В конце июля волонтерская группа из 16 разработчиков, известная как Bitcoin Red Team, прогнала ИИ-модели по 390 биткоин-репозиториям примерно за день и зафиксировала 4 962 находки, включая 85 с оценкой «критическая».
В течение нескольких дней уязвимость BTCPay Server, о которой группа сообщила в частном порядке, была использована на работающих серверах торговцев, что привело к опустошению узлов Lightning.
В августе разработчики Core Lightning призвали операторов обновиться или отключиться после того, как отчеты по проекту, сгенерированные ИИ, оказались точными.
Усилиям Red Team предшествовал эксплойт аппаратного кошелька Coldcard, в ходе которого злоумышленники вывели 594 BTC за 25 минут 30 июля. Убытки за четыре изъятия составили около 114 млн долларов.
Как часто будет применяться метка «легко обнаруживаемая» — и как быстро последуют исправления — станет видно из будущих рекомендаций и точечных релизов Bitcoin Core.
Источник: Bitcoin Magazine | Автор: Мика Зиммерман