脆弱性受付窓口の作り方
（公開ポリシー／連絡先例文付）
OEM監査や調査依頼で、意外と高確率で聞かれるのが 「脆弱性の受付窓口（PSIRT窓口）はどこですか？」 です。
ここで詰まる理由はシンプルで、社内では担当が分かっていても、外部に向けて“公開された窓口”が存在しないことが多いからです。
- 個人メールで受けてしまい、異動・退職で引き継げない
- 受付情報（製品名・版数・再現条件）が揃わず、調査が迷走する
- 「受領した／いつ返す」の一次返信ができず、期限（SLA）で炎上する
- 監査で「運用が回っている証拠（証跡）」が出せない
この記事では、Tier2〜Tier4の現場でも現実的に回るように、脆弱性受付窓口を“最小セット”で立ち上げる手順と、そのままWebに貼れる公開ポリシー／連絡先例文を用意しました。
先に結論：脆弱性受付窓口は「3点セット」で成立する
公開窓口を作るとき、最初から完璧を目指すと止まります。OEM監査や運用の実務で効くのは、まずこの 3点セット です。
1. 公開ページ
（/security など）
連絡先、対象範囲、ルール、一次返信の目安を掲載します。
2. 受付チャネル
（共有メール or フォーム）
“入口を1本化”し、個人のメールボックスでの漏れを防ぐのが目的です。
3. SLA＋証跡の型
受領連絡（いつ返すか）と、チケット化／保管場所をあらかじめ決めます。
この3つが揃うと、「窓口がある」「運用が回っている」の説明が一気に楽になります。
手順：脆弱性受付窓口を立ち上げる（最短で“監査に耐える”）
Step0：窓口名を決める（社内名称を統一）
- 呼び方を「PSIRT窓口」「脆弱性受付窓口」などに統一します。
- 監査資料・Webページ・社内台帳で同じ名称にします（表記ゆれは地味に痛い監査ポイントです）。
Step1：受付チャネルを1つにする（共有メールが最短）
最初はこれだけでOKです。
- 推奨： 共有メール（例：
psirt@/security@） - できれば： 担当者個人メール禁止（必ず共有窓口へ転送）
（フォーム運用は入力項目の設計・スパム対策などで意外と工数が増えるため、最初からフォームにこだわる必要はありません）
Step2：社内の一次返信SLAを置く（厳密でなくてOK）
公開ポリシーに「目安」を書けるように、社内で仮のSLAを決めます。
- 受領確認： 1〜2営業日以内
- 一次回答（影響あり/なし/調査中＋次回更新日）： 3〜5営業日以内
ポイントは「調査中＋次回更新日」を許可することです。完璧な結論を待って黙るより、一次返信のほうが信頼が上がります。
Step3：受付後の処理をチケット化する（証跡の起点）
最低限、次の情報が残る形にします（ツールはスプレッドシートでもOK）。
Step4：公開ページを作る（例文はこの後そのまま貼れる）
公開ページに載せるのは「細かいルール全部」ではありません。外部に伝えるべきは、次の5点だけです。
- 連絡先（入口）
- 対象範囲（何の報告を受けるか）
- やってほしいこと（報告に含める情報）
- やってほしくないこと（危険行為の禁止）
- こちらの返信目安（受領確認など）
Step5：security.txtを置く（できれば）
任意ですが、置くと「窓口が明確」になり、運用が安定します。実装は /.well-known/security.txt を設置するだけです（例は後述）。
そのまま貼れる：公開ポリシー（例文テンプレ）
下記を /security 等のページに貼り、【 】だけ書き換えてください。
※法務・契約条件（OEM/取引先）により表現調整が必要な場合があるため、公開前に社内確認を推奨します。
脆弱性報告のお願い
そのまま貼れる：連絡先（窓口）掲載文（短文版）
そのまま使える：security.txt（例）
URLは貴社ドメインに合わせて差し替えてください。CMS等へのコピペ用です。
受付後に必ず返す：一次返信テンプレ（受領＋次回更新日）
窓口を作っても、返信が遅いと逆効果です。まずはこの一次返信を“型”にしてください。
OEM監査で見られる「窓口の強さ」を上げる小技
- 個人メール禁止（共有窓口へ集約）
- 版数が切れる台帳（対象製品・対象版数が書ける）
- 証跡の保管場所（依頼原本／調査／回答書／提出履歴）
- 一次返信の目安（受領確認・次回更新日）
この4点が揃うと、監査の突っ込みが大幅に減ります。
OEM調査依頼・監査対応の進め方を整理して、いまの体制で回るようにしたい方はご相談ください。
【無料】オンライン相談を予約するよくある落とし穴（窓口が形骸化する原因）
- 公開ページはあるが、誰も見ていない／誰も返信しない
- 受領確認が遅く、報告者・OEMが不安になる
- 対象版数が曖昧で、調査が毎回ゼロから
- 証跡が散らばり、監査で再現できない
- 入口が複数で、受付漏れが起きる
FAQ：脆弱性受付窓口の作り方
OEMや取引条件によりますが、監査・照会対応を考えると「外部が参照できる窓口」があると強いです。最低限、共有メール＋掲載ページ（/security）があると運用が安定します。
問題ありません。受付時間を明記し、受領確認の目安（例：1〜2営業日）を示すだけでも、運用の信頼性が上がります。
最小は「連絡先」「対象範囲」「報告に含めてほしい情報」「禁止事項」「返信目安」です。長文より、迷わない記述が重要です。
必須ではありませんが、窓口の発見性が上がり、問い合わせの迷子が減ります。実装も比較的軽い（テキストファイルを置くだ先）ので、可能なら推奨です。
受付後の処理、システムで自動化しませんか？
窓口に届いた脆弱性情報を、手作業でExcelに転記して調べるのは大変です。
Auto PSIRT Cloudなら、受付から影響判定（トリアージ）、OEM向けの回答書出力までを一気通貫でサポートします。