協調的な脆弱性開示：開示プログラムの運営方法

協調的な脆弱性開示とは？

協調的な脆弱性開示（CVD）とは、新たに見つかった脆弱性を、修正または緩和策が利用可能になるまで発見者とベンダーの間で非公開に取り扱い、その後に公表する慣行です。CERT Guide to Coordinated Vulnerability Disclosureは、これを脆弱性の発見者から情報を収集し、関係者間でその情報の共有を調整し、脆弱性とその緩和策を一般を含めて開示することだと説明しています。

製品ベンダーにとって、CVDには2つの側面があります。外向きの側面である報告の受付とアドバイザリの公開を、このページで扱います。内向きの側面である検証、修正、リリースは、脆弱性管理ライフサイクルです。どちらも通常はPSIRTが運営します。

CVD、フルディスクロージャー、バグバウンティの違い

	協調的な開示	フルディスクロージャー	バグバウンティ
概要	非公開で報告し、修正し、合意した時期に公表	発見者がベンダーへの通知の有無にかかわらず、詳細を即座に公表	有効な発見に報酬を支払うプログラム
時期を決める主体	ベンダーと発見者が共同で（調整機関が入る場合も）	発見者	プログラムの規約（通常はCVDに準拠）
利用者へのリスク	最も低い：修正が存在するか期限が過ぎた時点で詳細が公開される	最も高い：防御側と同時に攻撃者も知る	CVDと同様
コスト	トリアージと対応にかかる人員の時間	計画外の緊急対応	人員の時間に加え、報奨金と多くの場合プラットフォーム手数料

バグバウンティは、脆弱性開示プログラム（VDP）の代わりではありません。VDPの上に重ねるインセンティブです。すべてのベンダーには、誰でも脆弱性を報告できる手段が必要です。バウンティは、一部の報告に報酬を支払うかどうかを決めるだけです。

脆弱性開示ポリシーに含める内容

脆弱性開示ポリシーは、プログラムの条件を定める公開文書です。脆弱性開示に関する国際規格であるISO/IEC 29147は、優先連絡手段（preferred contact mechanism）という1つの要素を必須とし、ほかにもいくつかの要素を推奨しています。網羅的なポリシーには次の内容を含めます。

• 報告方法。専用のアドレスまたはWebフォームと、公開された暗号鍵など、機密性の高い詳細を安全に送る手段。
• 記載すべき内容。影響を受ける製品とバージョン、再現手順、影響、報告者への連絡方法。
• 対象範囲。対象となる製品、バージョン、サービスと、サービス妨害や他のユーザーのデータへのアクセスなど、禁止するテスト手法。
• セーフハーバー。ポリシーに従った善意の調査に対して法的措置を取らないという約束。
• 報告者が期待できること。報告の受領をいつ通知するか、どのように進捗を伝えるか、修正までの目標期間。
• 開示までのタイムライン。詳細がいつ公開されるか、修正に時間がかかる場合はどうなるか。
• 公表。アドバイザリの掲載場所と、CVE IDを採番するかどうか。
• 謝辞。報告者をクレジットするかどうかとその方法、バウンティを支払うかどうか。

ポリシーは短く具体的にしてください。報告者はそれを読んで、報告しても安全か、労力に見合うかを判断します。

コピーして使えるポリシーのテンプレート

以下のテンプレートは、米国のCybersecurity and Infrastructure Security Agency（CISA）が公開している脆弱性開示ポリシーのテンプレートの構成に沿って、私たち自身の言葉で書いたものです。角かっこの部分を置き換え、公開前に許可に関する項を法務部門に確認してもらってください。

脆弱性開示ポリシー（[会社名]）
最終更新日：[日付]

当社は、当社の製品とサービスにおけるセキュリティ脆弱性の報告を
歓迎します。このポリシーでは、報告の方法と、当社に期待できることを
説明します。

許可
このポリシーに従うよう誠実に努めている限り、当社はお客様の調査を
許可されたものとみなします。当社はその調査を理由に、お客様に対して
法的措置を取ることも、それを勧めることもありません。このポリシーに
従った調査について第三者がお客様に法的措置を取った場合、当社は
その調査が許可されていたことを明らかにします。

ガイドライン
- 脆弱性の可能性を見つけたら、できるだけ早くお知らせください。
- プライバシーの侵害、本番システムの妨害、データの破壊や改ざんを
  避けてください。
- エクスプロイトは脆弱性の確認に必要な範囲でのみ使用してください。
  データへのアクセスや持ち出し、永続的なアクセスの維持、他の
  システムへの侵入には使用しないでください。
- 公開する前に、問題を修正するための妥当な時間を当社にお与えください。

対象範囲
対象：[製品、バージョン、ドメイン]
対象外：サービス妨害、ソーシャルエンジニアリング、物理的な攻撃、
[その他の除外項目]

報告の方法
報告は[[email protected]]または[Webフォーム]にお送りください。
機密性の高い情報は[公開鍵へのリンク]で暗号化してください。対象の
製品とバージョン、再現手順、影響を記載してください。

当社に期待できること
- 報告を受け取ってから[3]営業日以内に受領をお知らせします。
- 脆弱性の有無を確認し、修正までの経過を、遅れの理由も含めて
  お知らせします。
- [90日以内に]アドバイザリを公開し、ご希望があればお名前を
  記載します。

security.txt：連絡先を見つけやすくする

ポリシーは、研究者が見つけられて初めて機能します。2022年4月に公開されたRFC 9116は、security.txtを定義しています。これはHTTPSで/.well-known/security.txtに配置する小さなテキストファイルです。

Contact: mailto:[email protected]
Expires: 2027-09-30T23:00:00.000Z
Encryption: https://example.com/pgp-key.txt
Policy: https://example.com/security/disclosure-policy
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en
Canonical: https://example.com/.well-known/security.txt

• 必須：ContactとExpires。ファイルが古くならないよう、RFC 9116は有効期限を1年未満先に設定することを推奨しています。
• 任意：Policy、Encryption、Acknowledgments、Preferred-Languages、Canonical、Hiring。
• 署名：RFCは、Canonicalを設定したうえでOpenPGPのクリアテキスト署名を推奨しています。

Expiresの日付の前にカレンダーにリマインダーを入れておきましょう。期限切れのファイルは、誰も見ていないことを研究者に伝えてしまいます。

エンバーゴと開示のタイムライン

エンバーゴとは、報告から公表までの期間です。最もよく引用される基準はGoogle Project Zeroのポリシーです。ベンダーにはパッチを提供するまで90日が与えられ、詳細はパッチの提供から30日後に公開されます。もう少し時間が必要なベンダーは猶予期間を求めることができ、合計で最大104日までです。脆弱性がすでに実環境で悪用されている場合、期限は7日に短縮されます。

自社のポリシーで異なる条件を定めることもでき、多くの報告者はそれを受け入れます。重要なのは、タイムラインを文書化し、報告者に状況を伝え続け、期限を過ぎてからではなく期限前に延長を求めることです。緩和策を添えて予定どおりに公開されたアドバイザリは、沈黙よりも優れています。

CVE IDとCNA

ほとんどのアドバイザリには、顧客やツールが照合できるようCVE IDが付いています。IDを割り当てるのはCVE Numbering Authority（CNA）で、合意された範囲内でIDを割り当てる権限を持つ組織です。多くのソフトウェアベンダーは自社製品のCNAになっており、自社のスケジュールでIDを割り当ててレコードを公開できます。自社がCNAでない場合は、自社製品を範囲に含むCNA、またはCNA of Last ResortがIDを割り当てます。

複数の関係者間の調整

広く使われているライブラリ、プロトコル、チップの欠陥のように、多数のベンダーに同時に影響する脆弱性もあります。その場合は調整機関が、影響を受けるすべてのベンダーへの連絡と、1つの公表日の合意を支援します。

• CERT/CCは、カーネギーメロン大学ソフトウェア工学研究所に置かれ、複数ベンダーにまたがる案件を調整し、CERT CVDガイドを公開しています。
• EU各国のCSIRT。NIS2のもとで、各加盟国はCSIRTをCVDの調整機関として指定します。報告者とベンダーの間の信頼できる仲介者として機能し、開示のタイムラインを交渉し、複数の事業体に影響する脆弱性を取り扱い、匿名の報告も受け付けます。
• NIS2のもとで設立されたENISAの欧州脆弱性データベース（EUVD）は、2025年5月から運用されており、EUで調整されたものを含め、公知の脆弱性に関する情報を公開しています。

ISO/IEC 29147は、自社が両方の立場にあるケースも扱っています。つまり、他のベンダーの脆弱なコンポーネントを含む製品のベンダーとして、アップストリームに報告し、自社の顧客にも助言しなければならない場合です。

報告が届いた後の流れ

1. ポリシーで約束した期間内に受領を通知し、報告者に追跡IDを伝えます。
2. 報告を検証し、重大度を評価します。
3. 影響範囲を特定します：脆弱なコードやコンポーネントを含むすべての製品、リリース、サポート対象ブランチです。
4. 報告者に進捗を伝えながら、影響を受ける各ブランチについて修正してリリースします。
5. CVE ID、影響を受けるバージョン、対処方法、クレジットを記載してアドバイザリを公開します。機械可読のアドバイザリにはCSAFを使い、VEXで影響を受けない製品を顧客に伝えます。

役割、タイムライン、指標を含むプロセス全体は、脆弱性管理ライフサイクルで解説しています。

規制によりCVDポリシーが義務化されつつある

EUのCyber Resilience Actは、製造業者に「協調的な脆弱性開示に関する方針を策定し、実施する」ことと、サードパーティのコンポーネントに含まれるものを含め、脆弱性を報告するための連絡先を提供することを求めています（附属書I、第II部）。これらの義務は2027年12月11日から適用されます。CRAの要件をご覧ください。NIS2第21条(2)(e)は、必須事業体および重要事業体が講じるべきセキュリティ対策の1つとして、脆弱性の取扱いと開示を挙げています。米国では、大統領令14028が、脆弱性開示プログラムへの参加を含むソフトウェアサプライチェーンのガイダンスの策定を指示しました。

当局への報告は別の義務で、すでに適用されています。2026年9月11日以降、自社製品の脆弱性が実際に悪用されていることを知った製造者は、CRAのSingle Reporting Platformを通じて24時間以内に早期警告を送る必要があります。詳しくはCRAとはをご覧ください。

報告の価値は、出荷したものの記録で決まる

どの報告でも、最初の問いは同じです。「自社のどのリリースにこれが含まれているか」。CRACIはGitHub Actionsのビルドを自社のランナーで実行し、各ジョブが実際に取得したパッケージを記録します。推移的依存関係、CIキャッシュから復元されたパッケージ、どのロックファイルにも記載されていない依存関係も含まれます。ビルド履歴から、脆弱な依存関係を含んでいた過去のビルドがわかるため、影響を受けていた期間を把握できます。またインベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかがわかります。

CRACIはビルドとリポジトリをまたいでSBOMを集約し、監視対象のSBOMを継続的に再評価します。そのため、オープンソースのコンポーネントの脆弱性が公開されると、それが現れるすべての場所を確認できます。セキュリティチームは検出結果をトリアージして修正を担当するチームに送り、CRACIはVEXに対応しています。また、修正後はポリシーゲートで特定のCVEを含むビルドをブロックできます。脆弱性トラッキングをご覧ください。

協調的な脆弱性開示：よくあるご質問

協調的な脆弱性開示とは何ですか？

協調的な脆弱性開示（CVD）とは、脆弱性の発見者がベンダーに非公開で報告し、ベンダーが修正し、利用者が自衛できるようになった時点で（通常は当事者間で合意した日に）詳細を公表するプロセスです。ベンダーと連絡が取れない場合や複数のベンダーが影響を受ける場合は、CERT/CCや各国のCSIRTなどの調整機関が介入します。

VDPとバグバウンティの違いは何ですか？

脆弱性開示プログラム（VDP）は、発見に報酬を支払うことなく、誰に対しても脆弱性の報告方法と期待できる対応を示すものです。バグバウンティは、有効な発見に対して研究者に報酬を支払うもので、通常は定められた範囲内で、多くの場合バウンティプラットフォームを通じて行われます。ほとんどの組織はVDPから始めます。バウンティはその上に任意で追加するものであり、代わりになるものではありません。

脆弱性開示ポリシーには何を含めるべきですか？

最低限、報告方法、つまり連絡先のアドレスまたはフォームです。ISO/IEC 29147はさらに、報告に含めるべき内容、安全な連絡方法、報告者が期待できることとその時期、対象範囲、アドバイザリの公表方法、報告者のクレジット方法を明記することを推奨しています。多くのポリシーは、セーフハーバーの声明と開示のタイムラインも加えています。

security.txtとは何ですか？

security.txtは、RFC 9116で定義され、/.well-known/security.txtに配置されるプレーンテキストファイルです。研究者に脆弱性の報告先を伝えます。ContactとExpiresのフィールドを必ず含める必要があり、ポリシー、暗号鍵、謝辞ページへのリンクも記載できます。

一般的な開示期限はどのくらいですか？

最も広く引用される基準は90日です。Google Project Zeroはベンダーにパッチ提供まで90日を与え、パッチの30日後に詳細を公開します。脆弱性がすでに実環境で悪用されている場合の期限は7日です。自社のポリシーで異なる条件を定めることもでき、調整機関はケースごとに交渉します。

協調的な脆弱性開示ポリシーは義務ですか？

義務化が進んでいます。EUのCyber Resilience Actは、デジタル要素を持つ製品の製造業者に、CVDポリシーの策定と実施、および報告用の連絡先の提供を求めており、NIS2は必須のセキュリティ対策の1つとして脆弱性の取扱いと開示を挙げています。それ以外でも、顧客や調達規則からポリシーを求められることがよくあります。

CVE IDを取得するにはCNAである必要がありますか？

いいえ。CVE Numbering Authority（CNA）は自らの範囲内でCVE IDを割り当て、多くのベンダーが自社製品のCNAになっています。自社がCNAでない場合は、自社製品を範囲に含むCNA、またはCNA of Last ResortがIDを割り当てられます。