要約
- RFC 9943が示すのは、ある透明性サービスが特定のポリシーで署名済み声明を登録し、検証可能なデータ構造のレシートを発行した、という限定された事実である。それは成果物の全面的な安全証明やリリース許可ではない。
- どの発行者を信頼し、どのレシートを受け入れ、どのローカル規則で許可・保留・拒否を決めるかは、影響を修復できる組織の責任として残る。
「記録された」と「出してよい」は別の文である
「このコンポーネントには透明性レシートがある」という表示は、しばしば結論のように扱われる。2026年6月のIETF Standards Track RFCであるRFC 9943は、むしろそこから検討を始める。RFCは、ソフトウェア供給網の成果物について署名された声明を透明にするためのアーキテクチャを定める。製品の出荷可否を決める統治機関を定めてはいない。
発行者は、SBOM、支持表明、脆弱性情報、終息通知など、成果物に関する直列化可能な内容を署名できる。Transparency Service（TS）はその声明を登録できる。登録とは、声明を受け取り、TS自身のRegistration Policyを適用し、検証可能データ構造（VDS）に加え、Receiptを作る処理である。レシートは、たとえば当該声明がそのVDSに含まれることを示す証明を運べる。
これは重要な能力だ。追記型の履歴があれば、発行者の主張を後から静かに消したり書き換えたりしにくくなる。監査者は変更可能な紹介ページだけでなく、特定サービス内の記録と整合性を検査できる。しかし、包含証明は脅威評価でも、契約受入れでも、互換性試験でも、運用承認でもない。台帳が見せるのは主張の所在であり、その主張を採用した結果の損失を引き受ける者ではない。
四つの事実に同じ権限を与えない
第一に、発行者が声明へ署名した。署名は鍵と内容を結び付けられるが、その発行者が依拠者の期待した主体か、その種の主張をする権限を持つか、内容が正しいかを自動的に決めない。
第二に、特定のTSが登録した。RFC 9943のRegistration Policyは、COSE封筒の非不透明なヘッダーとメタデータに基づく登録前提である。厳格な場合も限定的な場合もある。登録結果が語るのは、そのサービスがその時点の政策で何を検査したかまでであり、全ての利用者に必要な安全、契約、運用の検査までではない。
第三に、依拠者が受け入れ可能なレシートを検証した。RFCは、少なくとも一つのレシート発行者について、検証鍵または証明書と結び付くアイデンティティを依拠者が信頼することを求める。依拠者は一つのレシートだけを検証してもよく、検証後に任意のローカル方針を適用してよい。つまりレシートの内側に、全組織共通の採用規則は入っていない。どのTS、鍵、発行者、証明形式、鮮度条件を採るかは利用者自身の判断である。
第四に、権限を持つ担当者または組織が運用判断をした。リリース責任者は許可できる。セキュリティ部門は保留できる。調達部門は限定契約の下で受け入れられる。運用者は稼働中の版を維持し、次版を拒否できる。権限、影響、修正手段が異なるこれらの行為を、正しい形のレシートが代行することはない。
この区別は現場で効く。声明が登録されていても、顧客がその発行者を信頼しないことはある。レシートが検証されても、新しい露出、ライセンス、互換性、期限切れ間近の例外のためにローカル規則が配備を止めることはある。緊急変更で狭い例外を使う場合も、証拠を省く理由にはならない。誰が許可し、いつ失効し、どのように後で見直すかを別に残す理由になる。
ポリシーにも時刻と版がある
RFC 9943はTS運営者がRegistration Policyや信頼アンカーを更新できるとする。同時に、登録時点で政策が求めた確認を監査者が再現できるだけの資料を提供しなければならない。したがって問うべきなのは「署名は通るか」だけではない。どのサービスの、どの政策版を、どの鍵で、どの声明に、いつ適用した結果か、である。
政策の更新は悪ではない。鍵の交代や規則の強化は必要になりうる。ただし今日の政策が昨日の登録の意味を書き替えてはならず、古いレシートが今日の企業のリリース政策を黙って代表してはならない。
VDSの順番についても同じ注意が要る。追記型構造は登録順を示せるが、RFC 9943は、Registration Policyが明示しない限り、その順番を声明の発行順とみなせないとする。ログ上の位置だけで、修正が助言より先だった、責任者が証拠を見てから決めた、決定と登録が同じ時間帯だった、とは証明できない。そこには独立した時刻と保管責任が必要だ。
また、透明性は真実の自動判定ではない。発行者は故意にも過失でも誤った声明を出し得る。後続声明は以前のものに取って代われるし、同一成果物について複数発行者が矛盾することもある。アーキテクチャはその履歴を調べさせる。誰を信じるかの裁定者にはならない。
足りないのは、もう一つの署名ではなく決定の記録
多くの組織は成果物のハッシュ、署名、レシート、ポリシー名を残す一方、「なぜこの版を通したか」を会話、管理画面の操作、追跡不能な緊急承認へ置き去りにする。問題が起きれば、何かが登録されたことは示せても、誰がどの根拠で通過を決めたかを説明できない。
そこでSCITTと区別したリリース決定レシートが有用になる。実質的な許可、保留、拒否、例外ごとに、不変の成果物版、声明と発行者、TS、登録政策版と登録時刻、レシート検証結果と再確認時刻、ローカル規則または例外、決定権者、結果、次の見直しまたは失効条件、訂正・ロールバック・異議申立ての経路を結ぶ。
これはRFC 9943の要件ではない。だからこそ標準に企業の承認権を仮託しない。試験詳細、顧客情報、攻撃に使える情報、完全な脅威モデルは保護できる。それでも、監査または是正の権限を持つ人は、どの証拠がどの決定へ至ったかを再構成できるべきだ。
自動化も境界を消さない。パイプラインがレシートを検証し、事前に選ばれた規則を実行しても、記録には規則の版、それを採択した権限、評価した入力、出力した結果が要る。「ログが許した」は、本当は誰かが以前にその規則を選んだという事実を隠す。
証拠の標準と、他者のリスクを決める権限は別である
RFC 9943は声明の管理・保存や、参加者の発見と変更通知を範囲外に置く。その抑制には意味がある。製造者、医療機関、公的調達者、ボランティア保守者は、同じレシートを検証しても同じリスク権限を持つふりをする必要がない。
技術的事実が制度判断の近道に使われるときに問題が生じる。調達が「登録済みだから調査は完了」と言う。配備チームが「包含証明だからリスク所有者も承認した」と言う。運用者が「発行者の署名があるから新たな脆弱性後も適切」と言う。いずれも限定された真実に、誰も記録しなかった権限を背負わせている。
強い実務は、証明できる性質だけを検証し、その意味を決める政策と時刻を保存し、それをどう使うかを決めた人を記録する。この順序なら暗号上の失敗と統治上の失敗を別々に見つけられる。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加