Bitcoin Core、AIへの単一のプロンプトで発見できるバグの1年間の公開延期を撤廃

1年間の公開延期がもはや意味をなさなくなった理由

Bitcoin Coreの従来の方針では、公開時期は深刻度に応じて決められていた。深刻度の低いバグは、次のメジャーリリースの公開から2週間後に公表された。中程度および深刻度の高いバグは、影響を受けた最後のリリースがサポート終了を迎えてから2週間後まで非公開とされた。この期間は、方針自体で「修正を含むメジャーバージョンが最初にリリースされてから約1年後」と説明されている。

この日程には理由があった。Bitcoin Coreは、Bitcoinノードの大半で稼働しているリファレンス実装であり、ノード運用者はアップグレードに時間をかける。長い公開延期は、詳細が公表される前にネットワークがパッチを適用できる時間を確保するためのものだった。その代償として、修正は通常、旧バージョンにはバックポートされなかったため、古いリリースを使う運用者は、プロジェクトが約6カ月ごとの公開を目指す次のメジャーバージョンを待つことになった。

慎重さは偶然ではなく、構造的なものだ。BitcoinのTaprootアップグレードのようなコンセンサス変更が、運用者がそれぞれの予定に合わせて導入できるよう、意図的に時間をかけた保守的な手順を踏むのはそのためだ。

「私たちのプロジェクトの性質に加え、アップグレードがゆっくり進む文化があるため、セキュリティ方針では長めの公開延期を優先しています」とPoinsotは書いた。「そのため一般に、セキュリティ修正はバックポートできず、次のメジャーリリースとともに初めてユーザーに提供されます」

AIはこのトレードオフを崩す。単純なLLMスキャンでバグを再発見できるなら、チャットボットを使える人なら誰でもすでにその欠陥にたどり着けるため、隠しても何も得られない。「見つけるのが簡単なこうした問題では、このトレードオフは適切ではありません。公開延期で得られるものはほとんどなく、修正済みリリースの提供を遅らせるだけです」とPoinsotは書いた。

新たな「容易に発見可能」な区分で実際に何が変わるのか

改定後の方針では、公開時期の設定に3つ目の区分が加わった。トリアージの段階で、脆弱性を「容易に発見可能」と判定できる。これは「単純なLLMプロンプトなど、ごくわずかな手間で発見できる」ものと定義されている。このラベルはAIが発見したバグに限らない。どのツールで発見されたかではなく、再発見にどれほど手間がかからないかによって決まる。

この区分のバグでは、対応があらゆる面で変わる。次のメジャーリリースに修正を1つ取り込む代わりに、メンテナーは現在サポート中のすべてのメジャーバージョンに修正をバックポートする。Bitcoin Coreの方針では直近3つのリリースをサポートするため、対象は3つのブランチとなる。また、可能な限り速やかにポイントリリースを公開する。セキュリティ勧告も、パッチ適用済みソフトウェアと同時に公開される。

それ以外は、引き続き深刻度の段階に従う。深刻度の低いバグは2週間のスケジュールを維持する。中程度および深刻度の高いバグは、約1年の期間が維持される。プロトコルレベルでコインを盗む、供給量を水増しする、あるいはチェーンを恒久的に分岐させる可能性がある重大なバグは、従来どおり標準方針の対象外で、個別に扱われる。

この例外が設けられているのには、正当な理由がある。Bitcoin Coreの歴史において、2018年9月にCVE-2018-17144として公表されたインフレーションバグは、特別な扱いが妥当な種類の欠陥だった。このバグにより、発行スケジュールに沿わずにコインが生成される可能性があった。新たな「容易に発見可能」という対応経路は、この区分には適用されない。重大なバグには今後も、ネットワーク全体へのリスクに合わせた個別対応が取られる。

2週間、1年、または「可能な限り速やかに」

この変更は、公開までの期間が大幅に短縮されたと捉えるのが最も分かりやすい。今日修正された中程度のバグは、通常なら約52週間非公開のままとなり、影響を受けた最後のリリースがサポート終了を迎えてから2週間後に初めて公表される。同じバグでも、容易に発見可能と判定されれば、勧告とともに「可能な限り速やかに」ポイントリリースとして公開される。その違いは、1年間か、メンテナー自身の説明に沿えば、対象を絞ったパッチの作成、レビュー、テストにかかる期間かということだ。

バックポートの確約も、変更のもう一つの柱だ。変更前は、通常、古いサポート対象ブランチのユーザーに修正が届くことはなく、次のメジャーリリースで提供されていた。今後は、古いサポート対象バージョンを使う運用者も、最新メジャーバージョンのすべての機能や動作変更を導入せずに、対象を絞ったポイントリリースを適用できる。アップグレードがゆっくり慎重に進むネットワークにおいて、これはパッチを実際に適用できる速さに関わる重要な変更だ。

メンテナー自身が指摘したリスク

迅速な対応には代償があり、Poinsotはプルリクエストでそれを率直に述べた。「この方針のもとでは、緩和策が開発ブランチで十分に『熟成』する時間を取れずにユーザーへ公開されることになるため、これは特に重要です」と彼は書いた。数日で公開される修正は、何カ月もかけた修正に比べて、レビューやテストに費やす時間が短い。

公開をさらに早めるべきかどうかについても、議論は分かれた。一部の貢献者は、修正のプルリクエストを公開すること自体が攻撃者への手がかりになり得ると主張した。リポジトリを自動で監視するのは容易なため、パッチと同時か、それより前に緩和策の案内を出す必要があるかもしれないという。一方、別の貢献者は、裁量によって、または遅らせて勧告を公開する案を提案した。Poinsotはこれを退け、詳細を示さずにユーザーに警告すると、影響を受けていない運用者まで慌てて移行しかねないと書いた。

このやり取りが重要なのは、新方針が自明な選択ではなく、意図的に設けられた中間策だと示しているからだ。採択された文面では、勧告を修正と同時に公開すること、曖昧な警告ではなく詳細を全面的に開示することが維持されている。

容易発見できるバグが初めて見つかったとき

新たな分類に該当する脆弱性はまだ登録されていないため、これは運用プロセスの変更であり、実際に存在するバグの開示ではない。最初の本格的な試金石は、トリアージで保守担当者が何かを「容易に発見できる」と判断し、保守対象の各ブランチ向けにポイントリリースを同時に公開し、勧告を発表するときに訪れる。

より広い意味でのシグナルは、AIを活用したバグ探しによって、ビットコインのエコシステムがすでに動かざるを得なくなったということだ。今年初め、Core Lightningは、AIが生成した脆弱性報告が正しいと判明したことを受け、ノード運営者にアップグレードするか、接続を切るよう伝えた。Bitcoin Coreのポリシー変更は、プロトコルの基盤層で参照実装が同じ判断を下したことを示している。再発見に大きなコストがかからないなら、秘密にしておく利点はほとんどなく、長期の公開延期によって遅れるのは修正版のリリースだけだ。

ノード運営者にとって、今日の時点で変わることはない。アップグレードのペースも変わらない。違いが生じるのは、次にバグが「容易に発見できる」と判断されたときで、その際はネットワーク史上かつてないほど短い予告期間で、パッチと勧告が同時に公開される。