要約

  • ISCが公開する脆弱性開示プロセスは、サポート対象のBINDとKeaについて、開示前情報の流れ、公式修正版の作成、公開時期をISCと参加する保守担当者の実務上の統制面に集中させる。https://btw.media/ru/sboi-f-root-pochemu-rezervirovanie-ne-zamenyaet-proveryaemuyu-gotovnost-k-otkazu
  • その力は、すべてのディストリビューション、ベンダー、開発者、運用者、フォークに更新を強制する法的または公的権限を意味しない。下流側には検証、導入、延期、独自対応、代替、フォークという選択肢が残る。

問題は「誰が命令できるか」だけではない

脆弱性が公表される前に誰が情報を持つか、誰が公式な修正版を作るか、どのリリースがサポート対象となるか、公開と修正版の提供がどの順序で行われるかは、運用上の結果を左右する。ISCの文書化されたプロセスでは、現在サポートされているオープンソース製品について段階的な脆弱性開示が行われ、選ばれた保守関係者が一般公開より前に通知を受ける場合があり、修正版が用意される。https://btw.media/ru/sboi-f-root-pochemu-rezervirovanie-ne-zamenyaet-proveryaemuyu-gotovnost-k-otkazu

この仕組みは、情報と時間の非対称性を生む。事前通知を受けた主体は、修正版の取り込み、パッケージ作成、互換性確認、顧客向け告知を準備できる。一方で、今回確認できた資料だけでは、詳細な適格要件、深刻度基準、保守担当者の選定基準を完全には確定できない。したがって、手続が完全に開かれているとも、恣意的に閉ざされているとも断定できない。

ISCの立場は、公式な修正版を準備し、サポート対象を定め、公開時期を調整する公式改善経路の中心にある。だが、公式修正版の作成権は導入命令権ではない。ディストリビューション、ベンダー、運用者、開発者は、それぞれの環境で検証、導入、延期、独自変更、代替、フォークを判断する。

既存の継続性論点から何が新しいのか

BTWの既存記事「Who can restore ISC continuity?」は、ソフトウェアが入手可能であることと、修復物を作成、認証、配布、展開できることの違いを扱った。また、F-Root事案を扱うロシア語の分析は、冗長性だけでは検証可能な回復準備を証明できないことを検討した。本稿の追加的な問いは、障害後の復旧ではなく、脆弱性が公になる前に誰が情報を受け取り、誰が公式修正版を準備し、公開後に誰が導入や代替を決めるのかである。

対象組織の読者向けリンクはISCの日本語ディレクトリ項目である。ただし、確認済み資料はISCとAS210764の関係を立証していないため、本稿はその関連を主張しない。

結論

ISCは、サポート対象のBINDとKeaに関する公式な脆弱性対応経路で、相当な実務上の権限を持つ。段階的な情報共有、公式修正版、サポート対象、公開時期をめぐる統制は、情報と時間への影響力を生む。https://btw.media/ru/sboi-f-root-pochemu-rezervirovanie-ne-zamenyaet-proveryaemuyu-gotovnost-k-otkazu

しかし、その影響力は普遍的な法的、政府的、契約的、企業的な命令権とは異なる。下流主体には導入、延期、緩和、代替、独自保守をめぐる別の統制面が残る。代替やフォークは可能でも、互換性、専門性、保守、信頼の費用を伴う。証拠が示すのは、単独支配ではなく、開示前に情報と時期が集中し、公開後に導入と remedial choice が分散する連続的な統制面である。