W3C標準の脆弱性開示・対応プロセスおよびポリシー

W3Cグループノート草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2026/DNOTE-security-disclosure-20260630/
最新公開バージョン:
https://www.w3.org/TR/security-disclosure/
最新の編集者草案:
https://w3c.github.io/security-disclosure/
履歴:
https://www.w3.org/standards/history/security-disclosure/
コミット履歴
編集者:
Simone Onofri (W3C)
Luca Lumini (招待専門家)
元編集者:
Philippe Le Hegaret (W3C)
フィードバック:
GitHub w3c/security-disclosure (プルリクエスト, 新しい課題, 未解決の課題)
リポジトリ
GitHubにあります。
バグを報告する。
コミット履歴。
メーリングリスト
public-security-disclosure@w3.org

概要

この文書は、W3C標準および 仕様(技術報告書)における疑わしいセキュリティ脆弱性を報告する方法を定義し、 問題が適切なW3Cプロセスを通じて トリアージ、確認、解決されるようにします。
これは、ソフトウェア実装またはW3Cの運用インフラストラクチャにおける脆弱性を報告するためのものではありません(範囲外を参照)。

この文書のステータス

この節は、この文書の公開時点におけるステータスを説明します。現在のW3C 公開物の一覧と、この技術報告書の最新版は、 W3C標準および草案 索引で確認できます。

注記

この文書は作業中であり、いつでも予告なく変更される可能性があります。

この文書は、セキュリティ関心 グループにより、 ノート トラックを用いて、グループノート草案として公開されました。

グループノート草案は、 W3Cまたはその会員によって承認されたものではありません。

これは草案文書であり、いつでも他の文書によって更新、置換、または廃止される可能性があります。 この文書を作業中のもの以外として引用することは不適切です。

W3C 特許 ポリシーは、 この文書に対していかなるライセンス要件またはコミットメントも課しません。

この文書は、 2025年8月18日のW3Cプロセス文書に従います。

1. はじめに

1.1 概要

World Wide Web Consortium(W3C)は、W3C標準および 仕様にいくつかのセキュリティ課題が存在し得ることを認識しています。W3Cは、研究者が 私たちの作業にフィードバックを提供してくれることに感謝しています。それは、Webを 安全に保つために不可欠だからです。W3C 仕様にセキュリティ課題を見つけた場合、あなたの協力は非常に重要です。

1.2 目的

このポリシーの目的は、W3Cにおける標準の 脆弱性開示プロセスがどのように機能するかを説明することです。

2. 範囲と適用

W3Cは、W3C勧告、 ノート、レジストリを含む技術報告書を公開する標準開発機関であり、 それらはWeb技術および仕様を記述します。これらの文書には 参照や例示的なソースコードが含まれる場合がありますが、W3Cは その標準の実装を構築または保守しません。

したがって、このポリシーは、W3C 仕様に記述された設計上の脆弱性またはセキュリティ課題に適用されます。

このポリシーは、次のものを対象としません:

3. プロセスとポリシー

W3Cは、研究者から寄せられる 作業へのコメントに感謝しています。W3Cからの対応は、 問題が見つかった技術報告書の種類、問題の深刻度、および 解決策の複雑さによって異なります。 W3Cは、セキュリティ課題をできる限り速やかに 解決し修正するよう努めます。これは、 ISO/IEC 29147(脆弱性開示 - VD)およびISO/IEC 30111(脆弱性 対応 - VH)の推奨手順に基づくプロセスに従います。

W3Cは、セキュリティ課題が 報告された文書の種類と成熟度に応じて、報告を処理し 振り分けます。

3.1 W3C標準における 脆弱性の報告

W3C 文書に脆弱性を見つけたと思われる場合は、協調的 開示のため、standards-vulnerability@w3.orgに連絡してください。

このメールアドレスは、W3Cチームおよび関連グループで構成され、 脆弱性開示および対応を調整するよう指定されたグループによる評価と対応の基準点として機能します。

PGP鍵を使用して、standards-vulnerability@w3.org宛てに暗号化されたメッセージを送信することが推奨されます。このメールには 公開アーカイブはありません。

プロセスを円滑にするため、あなたのアドバイザリには、ISO/IEC 29147およびNIST SP 800-216で推奨される次のような詳細を含めるべきです:

次の点に注意してください:

3.2 セキュリティ課題の受領 および確認応答(VD)

受領後、セキュリティ課題は3営業日以内に確認応答され、 報告者との 連絡チャネルが確立されます。

3.3 セキュリティ 課題の検証(VH)

確認応答後、セキュリティ課題は、その妥当性、技術的な 重大性、 重要度、および潜在的な影響を判断するために評価されます。

W3Cは、課題の妥当性を検証し、 15営業日以内に報告者へ通知することを目標とします。 セキュリティ課題を検証するために追加情報が必要な場合、W3Cは情報源に追加の詳細を求めます。

アドバイザリは、それが参照する文書の種類に応じて処理されます。

3.4 対応および 解決策の開発(VH)

W3Cはその後、報告者および セキュリティ課題の影響を受けるグループと協力します。これは 主に関連文書の更新を伴います。

3.4.1 W3C勧告 - 公開済み

これらは、完了し、コミュニティによるレビューを受けた標準です。

  • その勧告を作成した作業部会がまだ活動中である場合、作業部会は 対処するための最も適切な方法を決定する 責任を負います。確認された場合、 脆弱性は次の方法で対処される可能性があります:

    • 正誤表(規範的内容を変更しない軽微な課題または訂正の場合)。 W3C作業部会は、 勧告について報告された誤りの公開記録を保持しなければなりません。 これは少なくとも 四半期ごとにまとめられます。
    • 更新された勧告仕様文書(勧告の改訂)。
    • 課題に対応するためのまったく新しい文書。
  • 作業部会が終了している場合W3Cチームは、 課題に対処するための 最も適切な方法を決定する責任を負います。課題の深刻度により 次の手順が決まります:

    • 軽微な課題は正誤表で扱うことができます(グループが設立されていない場合は、W3Cチームが保守する可能性があります)。
    • より重要な更新については、W3C チームが別の方法を推進する場合があります。

W3Cプロセスに基づくクラス3または4の変更は、 より広範なレビューおよび特許ポリシー上の影響を引き起こす可能性があります。

課題は、GitHubのSecurity Issue機能で処理されます。

3.4.2 勧告候補(CR)および作業草案(WD) - 開発中

これらはW3C作業部会に採用された文書ですが、 まだ最終化されていません。

  • W3C作業部会は、技術報告書に関する 実質的なレビューコメントに速やかに正式に対応すべきです。

課題は、関連する作業部会のメーリングリストまたはGitHubのSecurity Issue 機能で処理されます。

3.4.3 編集者草案 - 初期段階/個人による貢献

これらはW3Cにおいて正式に採用された文書ではありません。 W3C 仕様として公開されていない編集者草案には、公式な地位はありません。

  • 課題は、その文書の編集者と処理および議論されるべきです。
  • 正式に採用されていない場合でも、課題は関連する作業部会の メーリング リストまたはGitHubのSecurity Issue機能でも議論できます。

課題は、関連する作業部会のメーリングリストまたはGitHubのSecurity Issue 機能で処理されます。

3.4.4 中止、廃止、または撤回された文書

  • 中止、廃止、または撤回と表示されたW3C技術報告書については、 セキュリティ課題の報告に応じて対応が行われる可能性は低いです。 それでも、チームは 文書のステータス(SOTD)にそれらを記載することを評価すべきです。

課題は、GitHubのSecurity Issue機能で処理されます。

3.4.5 コミュニティグループ報告書

これらはW3Cにおいて正式に採用された文書ではなく、 コミュニティおよびビジネスグループ プロセスがそれらを 規定しています

  • 見つかった課題は、その文書の編集者と処理および議論されるべきです。

課題は、関連するコミュニティグループのメーリングリストまたはSecurity Issue GitHub機能で処理されます。

3.4.6 会員による提出

これらはW3Cにおいて正式に採用された文書ではありません。 会員提出は、検討のために会員によって提案されるものです。

  • 見つかった課題は、その文書の編集者と処理および議論されるべきです。

課題は会員のポリシーに従って処理されます。

3.5 公開と周知(VD)

更新が利用可能になり、関連技術の更新および リリースを実装するために十分な時間が確保された後、 W3Cは、修正済み 脆弱性に関する情報の共有および公開開示を奨励します。これには、 脆弱性の説明、利用者が 影響を受ける標準を特定できる情報、影響、その深刻度、および 実装者と 利用者が是正するのに役立つ明確でアクセシブルな情報が含まれます。場合によっては、 公開によるセキュリティリスクがセキュリティ上の利益を上回る場合、 実装者および利用者が関連する 対策を適用する機会を得た後まで、開示が 遅らされることがあります。

W3Cは、脆弱性が解決された後にあなたの報告を 開示する要請を歓迎し、 公開発表を調整することを目指します。報告者が公に認められることを望む場合、W3Cは、報告者が公にクレジットされることを望むことを条件として、 脆弱性を報告したことについて謝意を示します。

A. 謝辞

この文書は、IETF Reporting Protocols VulnerabilitiesおよびW3Cセキュリティ開示 ベストプラクティスに基づいています。複数の個人がこの文書に貢献しました。編集者は特に、 Philippe Le Hegaret、Ian Jacobs、François Daoustに感謝します。