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

W3Cグループノート草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2026/DNOTE-security-disclosure-20260824/
最新公開バージョン:
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 概要

W3C の標準および仕様には、ユーザー、実装者、または Web プラットフォームにセキュリティリスクをもたらす設計上の 問題が含まれる場合があります。研究者やより広範なコミュニティからの報告は、W3C がそれらの問題を特定し、それらを評価して対処できる 人々へと引き継ぐのに役立ちます。

1.2 目的

このポリシーでは、W3C が、 W3C の標準および仕様における脆弱性の疑いに関する報告をどのように受領し、トリアージし、振り分け、 調整するかについて説明します。

2. 範囲と適用

W3C は、Web 技術および仕様を記述する W3C 勧告、 ノート、レジストリを含む技術報告を公開する標準化団体です。これらの文書には、 ときどき参照やソースコード例が含まれることがありますが、W3C は その標準の実装を構築または保守していません。

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

このポリシーは、以下を対象としません

3. プロセスとポリシー

W3C の対応は、問題が発見された技術報告の種類、 問題の深刻度、および対応の複雑さによって異なります。 W3C は、確認されたセキュリティ上の問題を不必要に遅延することなく解決するよう取り組みます。 このポリシーは、ISO/IEC 29147(脆弱性開示 - VD)および ISO/IEC 30111 (脆弱性対応 - VH)の推奨手順に基づいています。

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

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

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

このメールアドレスは、W3C チームによる初期トリアージの連絡窓口となります。トリアージ後、W3C チームは、 報告内容および影響を受ける仕様に応じて適切なグループを関与させます。通常、これには チーム連絡担当者、議長、編集者が含まれ、意見が必要な場合には他の人々も含まれることがあります。

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

課題 1

standards-vulnerability@w3.org の PGP 鍵は、公開前に利用可能になります。

プロセスを円滑に進めるため、報告には、 ISO/IEC 29147 および NIST SP 800-216 で推奨されている次のような詳細を含める必要があります:

以下の点にご注意ください:

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

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

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

受領確認後、セキュリティ上の問題について、その有効性、技術的な 深刻度、 関連性、および潜在的な影響を判断するための評価が行われます。

W3C は、問題の有効性を検証し、 15 営業日以内に報告者へ通知することを目指します。セキュリティ上の問題を検証するために さらに情報が必要な場合、W3C は情報提供元に追加の詳細を求めます。

W3C チームは、これらの対応 目標を追跡し、さらに多くの時間、 調整、または権限が必要な場合に報告をエスカレーションする責任を負います。

脆弱性報告は、それが参照する文書の種類に応じて処理されます。

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

W3C はその後、報告者および 影響を受ける文書を担当するグループと調整を行います。ほとんどの 場合、解決には主として関連文書の更新が伴います。

3.4.1 W3C勧告 - 公開済み

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

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

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

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

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

この問題は、 GitHub のセキュリティ Issue 機能で処理されます。

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

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

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

この問題は、関連するワーキンググループのメーリングリストまたは GitHub のセキュリティ Issue 機能で処理されます。

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

これらは W3C において正式に採択された文書ではありません。 W3C 仕様として公開されていない Editor's Draft には、公式な位置付けはありません。

  • この問題は、文書の編集者によって処理および議論されるべきです
  • 正式には採択されていませんが、この問題は関連する Working Group のメーリングリストまたは GitHub のセキュリティ Issue 機能でも議論できます。

この問題は、関連する Working Group のメーリングリスト、または有効になっている場合は該当するリポジトリの GitHub 非公開 脆弱性報告を通じて処理されます

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

  • 廃止、旧式、または撤回済みとされた W3C 技術報告については、セキュリティ上の問題の報告を受けても、対応が 行われる可能性は低いです。それでも、チームは 文書のステータス(SOTD)にそれらを記載することを検討するべきです。

この問題は、 GitHub のセキュリティ Issue 機能a>で処理されます。

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

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

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

この問題は、関連する Community Group のメーリングリストstrong> または GitHub のセキュリティ Issue 機能a>で処理されます。

3.4.6 会員による提出

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

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

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

3.5 公開と周知(VD)

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

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

A. 謝辞

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