WordPressサイトの脆弱性開示ポリシー（Vulnerability Disclosure Program）の作り方とsecurity.txtの設定

WordPressサイトでVulnerability Disclosure Program（VDP、脆弱性開示プログラム）を始めるには、「報告の受付窓口」「報告者向けのポリシーページ」「/.well-known/security.txt」「受け取った後の社内の対応手順」の4つをそろえます。特別なプラグインは不要で、メールアドレスと固定ページ、テキストファイル1つで始められます。この記事では、それぞれの作り方と、security.txt が配信されないときのつまずきどころ、報告を受けてから修正・公開までの進め方を解説します。

VDPとは何か、なぜ必要か

VDPは、外部の人がサイトの脆弱性に気づいたとき、どこに、どのように報告すればよいか、報告した人をどう扱うかを公開しておく仕組みです。報奨金を支払うバグバウンティとは異なり、VDPは謝礼を前提にしません。

窓口が無いサイトでは、善意の報告者が連絡先を見つけられず、問い合わせフォームやSNSに書き込んだり、報告をあきらめたりします。結果として、修正されないまま悪意のある人に先に見つかるおそれがあります。会員情報や注文情報を扱うサイト、法人のコーポレートサイト、プラグインやテーマを配布している開発者は、特に用意しておく価値があります。

なお、報告の内容によって適切な宛先は変わります。

• 自社サイトの設定や独自コードの問題：自社のVDPで受け付けます。
• WordPress本体の脆弱性：WordPressプロジェクト自身が報告窓口を設けているため、報告者にはそちらを案内します。
• 配布されているプラグインやテーマの脆弱性：その開発元か、WordPressの脆弱性情報を扱う Patchstack・Wordfence・WPScan などの窓口へ報告するよう案内します。

日本では、IPA（情報処理推進機構）が「情報セキュリティ早期警戒パートナーシップ」としてWebサイトの脆弱性の届出を受け付けています。自社に窓口が無いと、IPA経由で連絡が来ることもあります。

受付窓口を決める

窓口は、security@example.com のような専用のメールアドレスにするのが一般的です。決めるときは次の点に気をつけます。

• 担当者個人のアドレスではなく、複数人が読めるグループアドレスにする。異動や休暇で報告が埋もれるのを防ぎます。
• 迷惑メールフィルターで報告が隔離されないか、外部のアドレスから試しに送って確かめる。
• 連絡に暗号化を使いたい報告者向けに、OpenPGPの公開鍵を用意できるとなお良い（必須ではありません）。

問い合わせフォームで受け付けることもできますが、報告がWordPressのデータベースに保存される設定だと、サイトが侵害されたときに未修正の脆弱性情報まで読まれてしまいます。フォームを使う場合は、送信内容をデータベースに保存せず、メールで通知するだけの設定にするのが安全です。

脆弱性開示ポリシーのページを作る

次に、報告者に読んでもらうポリシーを固定ページとして公開します。下書きで作り、社内で確認してから公開します。

wp post create --post_type=page --post_title='脆弱性開示ポリシー' --post_name='security-policy' --post_status=draft

ポリシーには、少なくとも次の項目を書きます。

■ 対象範囲
  example.com および www.example.com で提供している Web サイト

■ 対象外
  サービス妨害（DoS）につながる試験、ソーシャルエンジニアリング、物理的な侵入、
  外部サービス（決済代行・メール配信など）自体の脆弱性、
  影響の説明がない自動スキャンの結果のみの報告

■ 調査時のお願い
  ・確認に必要な範囲を超えて情報を閲覧・取得・変更・削除しないでください
  ・他の利用者のアカウントやデータにアクセスしないでください
  ・修正が完了するまで、内容を第三者に公開しないでください

■ 報告に含めていただきたい情報
  対象の URL、再現手順、想定される影響、確認した日時、連絡先

■ 当社の対応
  受領の連絡：3営業日以内を目安
  進捗の連絡：調査結果と修正予定がわかり次第
  公開：修正完了後、報告者と時期を相談して公開します

■ 報告者の取り扱い
  本ポリシーに沿って誠実に行われた調査について、当社から法的措置をとることはありません

■ 謝礼
  本プログラムでは金銭的な謝礼はお支払いしていません。ご希望の方は謝辞ページに掲載します

■ 連絡先
  security@example.com

書くときのポイントは3つあります。1つ目は対象範囲を具体的に書くことです。サブドメインや外部に委託しているサービスを含めるかどうかがあいまいだと、想定外の場所を調べられます。2つ目は、受領連絡の目安を守れる値にすることです。守れない約束を書くと、報告者が待ちきれずに公開してしまう原因になります。3つ目は「報告者の取り扱い」の書き方です。調査を受け入れる姿勢を示す大切な項目ですが、法律上の扱いをどこまで約束できるかは会社の判断になるため、法務担当者と相談して文言を決めてください。

security.txt を設置する

security.txt は、セキュリティの連絡先を機械的に見つけられるようにするためのテキストファイルで、RFC 9116 で形式が定められています。ドメインの /.well-known/security.txt に置きます。

Contact: mailto:security@example.com
Expires: 2027-09-30T14:59:59Z
Preferred-Languages: ja, en
Policy: https://example.com/security-policy/
Canonical: https://example.com/.well-known/security.txt

Contact と Expires は必須の項目です。Expires は情報の有効期限で、1年より先の日付にしないことが推奨されています。期限が切れたファイルは古い情報として扱われるため、更新日をカレンダーに登録しておきます。

置き場所と配信の確認

ファイルは、WordPressのディレクトリではなく、ドメインのドキュメントルートに置きます。WordPressを https://example.com/blog/ のようなサブディレクトリに入れている場合も、置き場所は https://example.com/.well-known/security.txt です。

sudo mkdir -p /var/www/html/.well-known
sudo nano /var/www/html/.well-known/security.txt
curl -sI https://example.com/.well-known/security.txt

curl で 200 が返り、Content-Type が text/plain になっていれば配信できています。Apache で WordPress 標準の .htaccess を使っている場合、実在するファイルはそのまま配信されるため、追加の設定は通常いりません。

つまずきやすいのは Nginx です。ドットで始まるパスへのアクセスを一律に拒否する設定が入っていると、.well-known まで 403 や 404 になります。その場合は、拒否のルールより前に .well-known を許可する設定を置きます。

location ^~ /.well-known/ {
    allow all;
    try_files $uri =404;
}

location ~ /\. {
    deny all;
}

設定を変える前に設定ファイルのバックアップを取り、sudo nginx -t で構文を確認してから再読み込みします。SSL証明書の自動更新で .well-known/acme-challenge 用の設定を別に書いている場合は、変更後に証明書の更新テスト（certbot なら sudo certbot renew --dry-run）も通るかを確認します。

報告を受けてからの対応手順

窓口を公開する前に、報告が届いたときの流れを決めておきます。

1. 受領連絡：ポリシーに書いた期限内に、受け取ったことと今後の連絡方法を返信します。
2. 再現の確認：本番ではなく、ステージング環境で手順どおりに再現できるかを確かめます。報告に添付されたファイルやスクリプトは、そのまま本番で実行しないでください。
3. 深刻度の判断：影響を受けるデータ、悪用の難しさ、必要な権限をもとに優先度を決めます。CVSS のような共通の尺度を使うと、報告者との認識合わせもしやすくなります。
4. 修正：原因が独自コードなら修正し、プラグインやテーマが原因なら更新や一時的な停止で対応したうえで、開発元に報告します。修正前に、データベースとファイルのバックアップを取ります。
5. 報告者への連絡と公開：修正の完了を伝え、公開する場合は時期と内容を報告者と相談します。謝辞の掲載を希望するかも確認します。

調査の途中で、すでに不正アクセスを受けた形跡が見つかった場合は、脆弱性対応から侵害対応に切り替え、ログの保全や影響範囲の調査を優先します。

報告ごとに、受信日時、担当者、判断、連絡の履歴を記録しておくと、対応漏れを防げます。チケット管理の仕組みがあれば、セキュリティ報告用の非公開のプロジェクトを作って管理します。

プラグインやテーマを販売している事業者は、販売地域によって、脆弱性への対応や報告の体制が法律で求められる場合があります。たとえば EU のサイバーレジリエンス法（CRA）は、2026年9月から、悪用が確認された脆弱性についての報告義務の適用が始まっています（2026年10月現在）。対象になるかは事業の内容によるため、専門家に確認してください。

まとめ

• VDPは、受付窓口、ポリシーページ、security.txt、社内の対応手順の4つで構成します。報奨金を前提にしない点がバグバウンティとの違いです。
• 窓口は複数人が読める専用アドレスにし、フォームを使う場合は報告をデータベースに保存しない設定にします。
• ポリシーには対象範囲、対象外、調査時のお願い、対応の目安、公開の扱い、報告者の取り扱い、謝礼の有無を書きます。
• security.txt はドメインのドキュメントルートの /.well-known/ に置き、Contact と Expires を書きます。Nginx のドットファイル拒否設定に注意します。
• 報告を受けたらステージングで再現し、深刻度を判断して修正し、報告者と相談して公開します。

• WordPressのバグバウンティ対応方法
• サーバーが不正アクセスを受けたときの初動対応