Vulnerability Disclosure Policy雛形
（そのまま使える公開脆弱性受付文面）
脆弱性の報告窓口を公開していないと、研究者や取引先は「どこに連絡すればいいのか」が分かりません。
CISAは脆弱性開示ポリシー（VDP）が、何が対象か、どう送るか、どう対応するか を明確にし、報告者に期待値を示すものだと整理しています。
さらに CISA の BOD 20-01 では、公開ポリシーに対象範囲、報告方法、対応の考え方を含めること、そして報告の追跡、内部調整、優先順位付け、コミュニケーション、目標時間（timelines）を定めることが求められています。
FIRST の PSIRT Services Framework でも、PSIRTは明確な連絡チャネルを公開し、好ましい報告手段を定義し、psirt@ や security@ のような共通窓口を用意し、暗号化された報告手段を推奨し、迅速に受領確認を返すべきと整理されています。
そのまま使える：Vulnerability Disclosure Policy雛形
使い方： 以下をそのままWebページ（例：https://example.com/vulnerability-disclosure-policy）に貼り、【 】だけ置き換えてください。
使い方のコツ（運用で詰まらないために）
1. 対象範囲は“広すぎず狭すぎず”
「全部対象」は現場が破綻しやすく、「一部だけ」は報告が迷子になりやすいです。まずは公開している主要製品/サービスに絞ると運用しやすいです。CISA の VDP テンプレートでも、どのシステムが in-scope か を明示することが重要とされています。
2. 受領確認SLAを必ず書く
FIRST は、受領確認そのものはすぐでき、信頼関係づくりに重要だとしています。また、外部からの報告への応答時間は社内SLAで定義すべきだとも述べています。
3. 暗号化手段を用意する
PSIRT には機密情報が届く前提なので、FIRST は PGP/S/MIMEやHTTPSフォーム のような安全な送信手段を推奨しています。
4. security.txt も併用すると見つけてもらいやすい
RFC 9116 は、脆弱性報告先やポリシーを機械可読に公開するための security.txt を定義しており、Contact、Policy、Expires などの項目を持ちます。Contact と Expires は必須で、Policy で VDP ページへ案内できます。
security.txt 最小例（コピペ用）
自社ドメインの /.well-known/security.txt に以下の内容を配置します。
外部からの脆弱性報告を適切にさばく「自社向けトリアージの判断基準」を整理したい方はご相談ください。
【無料】オンライン相談を予約するよくあるNG例（VDPが機能しなくなる原因）
- 連絡先が個人メールのみ
→ 異動・退職で対応が死にます。psirt@/security@など共有窓口に寄せます。 - SLA（返信目安）が書いていない
→ 報告者の不信感が上がります。受領確認だけでも明記します。 - 禁止事項だけが長い
→ “報告してよいのか”が分からず、善意の報告を逃します。CISA テンプレートのように、歓迎姿勢と期待値をセットで書きます。 - security.txt が古い（期限切れ）
→ RFC 9116 は Expires を必須とし、1年以内の更新を推奨しています。
FAQ：VDP（公開ポリシー）について
いいえ。VDPは「脆弱性報告の受け付け方と対応方針」を定めるもので、報奨金の有無は必須ではありません。CISAのVDPテンプレートも、まずは報告経路と範囲、対応方針を明確にすることに重点があります。
実務では、公開ページに加えて security.txt を置くと、研究者や自動ツールが報告先を見つけやすくなります。RFC 9116 がそのための形式を定めています。
日本語主体でも構いませんが、RFC 9116 には Preferred-Languages があり、英語併記も可能です。海外からの報告の可能性があるなら、最低限の英語表記もあると安全です。
報告を受けた後の「トリアージ」、自動化しませんか？
外部から届いた脆弱性報告を、素早く自社のSBOMと照らし合わせて影響を判定する。
Auto PSIRT Cloudなら、そのトリアージ業務をAIが自動でサポートします。