要約

  • 2026年9月10日付のdraft-bruhns-securitytxt-product-security-00は、RFC 9116形式に任意のProduct-SecurityとProduct-Security-Policyを加える提案である。
  • 前者は製品脆弱性の連絡URIを優先順に示し、後者は対象範囲やトリアージ、開示方針などを記すHTTPSのポリシーへ導く。
  • 文書は個人Internet-Draftであり、IETFワーキンググループによる採択も標準承認もない。IANAの現行レジストリにも両フィールドはない。
  • 専用窓口は初動の振り分けを助けるが、型番、版、再販品、組み込み部品を担当組織へ結び付ける証明にはならない。

受付番号の後に残る空欄

研究者が保有しているのは、ある装置のファームウェア画像と再現手順だとする。ブランドのサイトには製品セキュリティ窓口があり、送信後すぐ受付番号も返る。ところが担当者は、その型番は買収前の事業部が扱っていたと答える。旧事業部は、対象版の保守を地域パートナーへ移したという。

このときメール経路は正常である。欠けているのは、当該成果物を誰の範囲に入れたかという判断だ。連絡先URIは報告の出発点を示す。コードを変更できる主体、修正版を配布できる主体、開示時期を調整する主体が同じとは限らない。

製品名は長く残り、責任は動く。OEM供給、事業売却、保守終了、オープンソース部品の取り込みによって、同じロゴの下に異なる責任線が生じる。ドメイン単位の案内だけでは、その履歴を復元できない。

提案は二つのフィールドに限られる

DatatrackerはProduct Security Fields for security.txtを個人Internet-Draftとして掲載している。履歴には9月10日提出の第00版だけがある。Internet-Draftは検討用の文書であり、この段階からIETFの支持、ワーキンググループ採択、RFC化を読み取ることはできない。

第00版によれば、Product-Securityは複数記載できる。各行は製品の脆弱性を報告するURIを持ち、Contactと同じURI上の制約を受ける。記載順が発行者の優先順位となる。

Product-Security-Policyは一つだけで、HTTPSのポリシーを指す。そこでは対象製品、受領確認とトリアージ、応答時間の目安、開示とエンバーゴ、匿名報告、善意の研究者への保証を説明することが望まれている。

ポリシーに対象範囲を置く設計は合理的だ。ただし、リンクの存在は内容の精度を保証しない。製品識別子や版が自動的に照合されるわけでもない。広いブランド名だけのページと、保守終了版まで列挙したページは、同じフィールドからは区別できない。

IANAへの依頼はまだ結果ではない

草案のIANA Considerationsは、二つの名前をExpert Reviewで登録するよう求めている。観測時点のIANA security.txt fieldsレジストリには、どちらも掲載されていない。現行表にはContact、Expires、Canonical、Encryption、Policy、Preferred-Languagesのほか、登録済み拡張のCSAF、Bug-Bounty、Hiringなどがある。

依頼文と登録済み状態は分けて扱う必要がある。RFC 8126のExpert Reviewは、指定された専門家が登録方針に照らして申請を評価する仕組みである。個人草案の提出だけで、その判断を先取りすることはできない。

未登録フィールドを試す余地はある。RFC 9116は、未知の拡張フィールドをパーサーが無視するよう定めている。そこで新草案は、従来のContactでも製品報告を受けられる状態を保つよう勧める。古いパーサーの退路は残るが、相互運用が実証されたことにはならない。

Web上の起点と製品台帳は違う

RFC 9116の通常の適用範囲は、ファイルを取得したドメインまたはIPアドレスに結び付く。親ドメインや子ドメインへ自動的に広がらない。組織は製品やサービスの情報を同じ形式で公開できるが、規格が型番、版、保守主体の台帳を提供するわけではない。

報告側にはパッケージ座標、型番、シリアル範囲、版、ビルド、commitといった手掛かりがある。公開側にはWebの起点、連絡URI、ポリシーがある。両者をどの規則で照合したかを残さなければ、後の監査で分かるのは「ブランドのドメインへ届いた」という事実だけだ。

この照合は時点にも依存する。買収前と後で窓口が変わり、長期サポート版だけ別会社が維持し、組み込み部品だけ上流へ渡ることがある。現在のポリシーページで過去の判断を上書きすれば、当時の担当範囲は失われる。

発行の真正性は担当能力を証明しない

RFC 9116はExpiresを必須とし、Canonicalを用意し、署名を推奨する。古い連絡先を見分け、意図した配置場所を示し、改ざんによる連絡先のすり替えに対抗するためである。

しかし、署名が正しくても署名者が当該部品を保守しているとは限らない。Canonical URLが確認できても製品版の範囲は決まらない。有効期限内でも、受信したチームが案件を引き受けた証拠にはならない。それぞれの制御が答える問いを広げ過ぎてはいけない。

また、security.txtの有無はシステムを試験する許可を与えも奪いもしない。製品ポリシーにセーフハーバーの説明があっても、製品、行為、法域の範囲は本文に従って判断する必要がある。

成果物から担当者までの受け渡しを残す

受け渡し記録には、報告者が示した製品系列、型番、部品、パッケージ、版、ビルド、ファームウェア分岐、流通経路を、判明する範囲で保持する。続いてsecurity.txtの取得元とCanonical URL、取得時刻、Expires、署名結果、選択したProduct-Security行とその優先順位を記録する。

さらにProduct-Security-PolicyのURLと内容ハッシュまたは版を固定する。受信側は、どの範囲条項を根拠に受理、拒否、転送したか、どのチームが保管責任を取ったか、どの案件番号または引継ぎ番号を返したかを残す。脆弱性の機密部分を公開しなくても、判断そのものは保存できる。

これはDaniel Kadeによる編集上の提案であり、第00版、RFC 9116、IANAの要求ではない。稼働中の窓口を確認する作業とも異なる。窓口の記録は届いたことを示し、成果物の記録は届いた後の責任判断を示す。

情報源