更新日 2026年6月14日5 分で読めます
企業サイト向け Vulnerability Disclosure と security.txt
信頼できるセキュリティ連絡経路を持ちたい小規模企業のための、実践的な security.txt と脆弱性報告ワークフロー。
要点
- security.txt は、研究者がセキュリティ連絡先を探すための予測可能な場所を提供します。
- その連絡先の背後にあるメールボックスは監視され、社内で適切にルーティングされる必要があります。
- 公開ポリシーは、インシデントが起きる前に混乱を減らします。
security.txt が解決すること
研究者や顧客が、セキュリティ問題を問い合わせフォーム、サポート inbox、SNS メッセージのどこに送るべきか推測する必要はありません。security.txt は脆弱性報告の標準的な経路を作ります。
ファイル自体は小さいものですが、実在する連絡先、canonical URL、policy URL、優先言語を含むことで運用成熟度を示します。
実務上の最小構成
- canonical ドメインで /.well-known/security.txt を公開します。
- security@example.com のような監視対象の security メールボックスを使います。
- 脆弱性開示ポリシーまたは security ページへリンクします。
- support と contact の担当者が security report の転送先を理解していることを確認します。
対応ワークフロー
Web サイトは入口にすぎません。企業レベルの構成には、対応責任者、severity triage、証拠の保存、修正追跡、有効な報告を受領したことを伝える短いテンプレートも必要です。
よくある失敗
- 誰も監視していない security メールボックスを公開する。
- 会社 alias ではなく個人メールアドレスを使う。
- ドメイン移行後に canonical URL を更新し忘れる。
- 開示対応を運用ワークフローではなく法務ページだけとして扱う。