security.txtを置くだけで脆弱性報告窓口になりますか？

それだけでは足りません。security.txtが知らせるのは連絡先だけです。受付後の返信期限やトリアージの担当者を決めておかないと、届いた報告が放置されてしまいます。手順の決め方は/practice/の関連記事にまとめています。

報告してきた人に報奨金を払う必要はありますか？

義務はありません。まずは謝辞の掲載と、公表方針をはっきり示すことから始める企業が多いです。報奨金制度を作るかどうかは、受付と修正の体制が回るようになってから判断します。

FDEとして顧客先にいるとき、見つけた脆弱性は自分で直してよいですか？

契約と顧客の手順に従います。まず顧客の窓口と製品ベンダーの窓口へ報告し、修正の範囲は合意してから進めます。FDEの役割の範囲は/about/の記事で確認できます。

開発元の連絡先がわからないときはどうすればよいですか？

国内で使われているソフトウェアであれば、IPAへ届け出ることができます。JPCERT/CCが開発者を探し出して調整し、対策がそろった段階でJVNで公表されます。

脆弱性報告窓口の作り方は？security.txtとIPA届出で整える受付フロー

図解：脆弱性報告窓口の受付フロー（4段階）

1. 受付security.txtで公開した専用アドレスかフォームで報告を受け取り、受領したことを報告者へ返信する
2. トリアージ再現できるか、影響範囲と深刻度はどうかを確認し、担当者と修正方針を決める
3. 修正・調整修正版を作り、関係するベンダーや調整機関と公表日をすり合わせる
4. 公表修正版を出すのと同時に、アドバイザリを公開して報告者への謝辞を載せる

security.txtで公開した窓口に届いた報告を、受領の返信から公表・謝辞の掲載まで4段階で処理する流れ（RFC 9116・ISO/IEC 30111をもとにFDE総研編集部が作成）

図解：自社窓口とIPA届出制度の違い

自社の脆弱性報告窓口

報告者が開発元へ直接連絡する
連絡先はsecurity.txtやWebサイトで公開する
受付から公表までのスケジュールを自社で決められる
海外の研究者からの報告もそのまま受けられる

IPA／JPCERT/CCの届出制度

報告者はIPAへ届け出る
JPCERT/CCが開発者との調整を担う
公表はJVNで行われる
開発者の連絡先がわからないときの受け皿になる

自社窓口は開発元が直接受け付けて公表時期を決める経路、IPA届出はJPCERT/CCが調整してJVNで公表する公的な経路（IPA・JVNの公開情報をもとにFDE総研編集部が作成）

図解：企業規模ごとの窓口体制

小規模・スタートアップ専用アドレスとsecurity.txtを用意し、一次応答の期限を決めて運用する

中堅企業受付フォームと深刻度の判断基準を整え、開発チームへの引き継ぎ手順を書面にしておく

大企業・製品ベンダーPSIRTを置いて公開ポリシーやバグ報奨金制度を運用し、調整機関と日常的に連携する

小規模は専用アドレスとsecurity.txtから始め、中堅は判断基準と引き継ぎ手順、大企業・製品ベンダーはPSIRTと公開ポリシーへ広げる体制の目安（FDE総研編集部が作成）

脆弱性報告窓口は、社外の研究者や利用者が見つけた欠陥を、正しい担当者へ非公開で届けるための公式な連絡経路です。FDE総研では、窓口を「連絡先を公開する」「届いた報告を処理する」「公表を他者と調整する」の3層に分けて設計することを勧めます。本記事は2026年11月時点で公開されているRFC 9116、IPA「情報セキュリティ早期警戒パートナーシップ」、ISO/IEC 29147・30111をもとに書いています。

脆弱性報告窓口とは何で、なぜ必要なのか？

脆弱性報告窓口は、社外の発見者が迷わず安全に脆弱性を伝えられる公式経路です。報告の放置やSNSでの暴露を防ぎます。

窓口が無いと何が起きるのか？

窓口が無いと、報告は問い合わせフォームや営業宛てメールに流れて埋もれます。発見者が公開に踏み切る原因にもなります。

発見者は善意でも、連絡先が見つからなければ代表メールやSNSのDMに送るしかありません。受け取った側にセキュリティの判断ができず、数週間返信しないまま発見者が「無視された」と受け止める。こうしたすれ違いは、規模を問わず多くの組織で起きています。公表されている情報漏えい事案を見ても、外部からの指摘が社内の適切な部署に届くまで時間がかかったという経緯は珍しくありません。

VDPとバグバウンティは何が違うのか？

VDP（脆弱性開示ポリシー）は受付ルールの宣言です。バグバウンティはそれに報奨金を上乗せした制度で、最初に整えるべきなのはVDPです。

項目	VDP（脆弱性開示ポリシー）	バグバウンティ
目的	報告を受け付ける経路とルールを示す	報奨金で調査を促す
費用	運用する人の工数が中心	報奨金と運営プラットフォームの費用
前提条件	受付と一次対応ができる体制	VDPの運用が安定していること
向く組織	すべての組織	トリアージ要員を確保できる組織
主なリスク	返信が遅れると信頼を失う	報告が急増し、処理が追いつかなくなる

VDPが無い状態でバグバウンティを始めると、報告件数に対応力が追いつきません。まずはVDPとsecurity.txtで「連絡先」と「約束」をはっきりさせるのが現実的な順番です。

security.txtで連絡先を公開するには？

security.txtは、/.well-known/security.txt にテキストファイルを置いて連絡先を示す標準です。RFC 9116では、ContactとExpiresの2項目が必須とされています。

必須項目と推奨項目は何か？

ContactとExpiresは必須です。運用上はPolicy、Preferred-Languages、Canonicalも加えておくと、受付時のすれ違いが減ります。

RFC 9116（2022年4月、IETF発行）で定められた主なフィールドは次のとおりです。

フィールド	必須/任意	役割	運用上の注意
Contact	必須（1つ以上）	報告先のメールアドレス（`mailto:`）またはURL	個人ではなく共有の受付アドレスを指定する
Expires	必須（1つだけ）	ファイルの有効期限	RFCでは1年以内に設定することを推奨
Encryption	任意	暗号化に使う公開鍵の場所	鍵の更新を忘れやすい
Policy	任意	VDP本文へのリンク	対象範囲とセーフハーバー（善意の報告者を法的に追及しない旨）を明記する
Preferred-Languages	任意	対応できる言語	例: `ja, en`
Canonical	任意	このファイルの正規URL	署名と組み合わせると改ざん検知に役立つ
Acknowledgments	任意	謝辞ページ	報告者の掲載は本人の同意を得てから

記述例です（ドメインは説明用の例です）。

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-10-31T23:59:59+09:00
Encryption: https://example.com/.well-known/pgp-key.txt
Preferred-Languages: ja, en
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security/policy

設置で失敗しやすい点は何か？

失敗が多いのは、Expiresの期限切れ、HTTPSで配信していないこと、Contactの宛先を誰も見ていないことの3点です。設置後に定期点検の日程を決めておきましょう。

RFC 9116では、HTTPSで配信し、text/plain で返すことが求められています。OpenPGPによる電子署名も推奨されています。FDE総研編集部の見方では、ファイルを置くこと自体より、Contactの宛先を誰が毎日確認するかを決めることのほうが難しい部分です。Expiresを1年後に設定したら、その1か月前に更新タスクを登録しておくと期限切れを防げます。

受付から公表までの流れは？

受付から公表までは、受領通知、トリアージ、修正、公表調整、事後レビューの5段階で進めます。ISO/IEC 30111の処理プロセスと同じ流れです。

標準的な5ステップは？

受領通知：報告を受け取ったら、まず受け取ったことを返信する。目安の期限は自社のVDPに書いておく。
トリアージ：再現できるかを確認し、CVSS（FIRSTが2023年11月にv4.0を公開）などで深刻度を評価し、影響範囲を確認する。
修正・緩和：恒久的な修正と、それまでの暫定回避策を用意する。
公表調整：報告者や調整機関と公表日、クレジット表記、CVE採番の有無を合意する。
事後レビュー：原因の分類、検知できなかった理由、再発防止策を記録する。

ISO/IEC 29147は社外とのやり取り（開示）を、ISO/IEC 30111は社内の処理プロセスを扱う国際規格です。この2つを対で参照すると、抜け漏れを点検しやすくなります。

公表までの期限はどう決めるのか？

公表の期限は、報告者との合意で決めるのが原則です。目安として、業界で広く知られた90日型の開示ポリシーを参考にする組織が多くあります。

よく知られた例として、Google Project Zeroは報告から90日を開示期限の基本としています。ただし、これは研究チームの方針であり、法的な基準ではありません。修正の難しさや、既に悪用されているかどうかで期間は変わります。期限を延長したい場合は理由と見込みを報告者に説明し、経過を記録に残しておくと、後でトラブルになりにくくなります。

自社窓口とIPA届出はどう使い分ける？

自社窓口は自社の製品やサイトの報告を直接受ける経路です。IPA届出は、当事者間の調整が難しい場合などに使える公的な調整経路です。

IPA届出制度の仕組みは？

IPAの「情報セキュリティ早期警戒パートナーシップ」では、ソフトウェア製品とウェブサイトで調整のルートが分かれています。製品の場合はJPCERT/CCが開発者との調整を担います。

区分	受付	調整役	公表
ソフトウェア製品	IPA	JPCERT/CCが製品開発者と調整	JVN（Japan Vulnerability Notes）で公表
ウェブサイト	IPA	IPAがサイト運営者に通知	原則として個別のサイト名は公表しない

この制度は経済産業省の告示「ソフトウェア製品等の脆弱性関連情報に関する取扱規程」を根拠に運用されています。具体的な手順はIPAとJPCERT/CCが公開している「情報セキュリティ早期警戒パートナーシップガイドライン」に書かれています。届出の件数はIPAが四半期ごとに公表しているので、最新の数値は同機構の公式ページで確認してください。

自社窓口を持つ企業でもIPAから連絡が来るのか？

自社窓口を持っていても、発見者がIPAに届け出ればIPAやJPCERT/CCから連絡が来ます。両方の経路から受け付けられる準備が必要です。

発見者がどちらの経路を選ぶかは自由です。調整機関から連絡が届いたときに「担当がいない」状態を避けるため、JPCERT/CCの製品開発者リストへの登録を検討し、調整機関からの連絡を受ける窓口も自社窓口と同じ宛先に集約しておくと混乱が少なくなります。EU域内で製品を提供する場合は、EUサイバーレジリエンス法（CRA）で2026年9月11日から適用が始まった報告義務（悪用が確認された脆弱性の当局への報告）も対象になるため、法務部門と確認しておく必要があります。

企業規模でどう体制を変えるべきか？

企業規模による違いは「誰が兼務するか」と「受付から何時間で一次判断するか」です。最小構成は小規模企業でも作れます。

規模別の体制例は？

小規模企業は兼務の2人体制で十分始められます。中堅以上の企業はPSIRT（製品セキュリティ対応チーム）やCSIRT（組織のセキュリティ事案対応チーム）を受付の主体に据えます。

規模の目安	受付主体	最低限そろえるもの	外部連携
小規模（開発者が数名〜数十名）	CTOと開発リーダーの兼務2名	security.txt、共有メール、簡易版VDP	IPAやJPCERT/CCの連絡を受けられること
中堅	情報システム部門または開発部門の担当者を指名	VDP、トリアージ基準、チケット管理	法務・広報との連絡網
大企業・製品ベンダー	PSIRT/CSIRT	ISO/IEC 30111に沿った手順、CVE採番体制	JVN、海外の調整機関、各国の規制当局

人数の目安は業種によって変わるため、上の表は「誰が担うか」を整理するための例として使ってください。

小さく始めるときの優先順位は？

最初の優先順位は、宛先の確保、受領通知のテンプレート、エスカレーション先の3つです。報奨金や専用ツールは後回しで構いません。

現場の感覚として、立ち上げ時に最も効くのは「誰が、いつまでに、何を返すか」を1枚の表にまとめることです。ツールを入れる前に、受領通知の文面と「深刻度が高い場合は誰に電話するか」を決めておくだけで、初動の迷いは大きく減ります。

FDEが顧客環境で脆弱性報告を受けたら？

FDEが顧客環境で脆弱性の報告や発見に直面したら、自分で直す前に、顧客の窓口と自社の窓口の両方へ正式な経路でつなぐことが最優先です。

誰の脆弱性かをどう切り分けるのか？

まず、影響を受けるのが顧客のシステムか、自社製品か、第三者のOSSかを切り分けます。それぞれ報告先が変わります。

脆弱性の所在	一次報告先	FDEがやるべきこと	避けるべきこと
顧客が自前で開発したシステム	顧客のセキュリティ窓口	事実と再現手順を書面で共有する	契約外の修正を独断で行う
自社製品・自社が提供したコンポーネント	自社のPSIRT/窓口	自社窓口へ起票し、顧客への説明方針を合わせる	顧客にだけ口頭で伝えて終える
第三者のOSS・ベンダー製品	開発元の窓口またはIPA	顧客と自社の合意を取ってから報告する	顧客の環境情報を含めたまま外部へ送る

FDE（Forward Deployed Engineer）は、Palantirが広めた「顧客の現場に入り込んで実装まで担うエンジニア」です。顧客の本番データや社内ネットワークに近い位置で働くため、脆弱性に気づく機会が多い職種といえます。一方で、顧客の秘密情報を扱う立場でもあるため、外部への報告に何をどこまで含めてよいかを事前に合意しておく必要があります。

現場での判断で迷いやすい点は？

迷いやすいのは「すぐ直せるから直す」という判断です。修正の可否より先に、記録を残すことと、報告経路を守ることを優先するのが安全です。

FDE総研編集部の整理では、FDEが現場で迷いやすい判断は次の3つです。

小さな修正を独断で入れる：直したこと自体は正しくても、変更の記録や承認が欠けると、監査や事後の原因調査で説明できなくなります。
Slackでの報告で済ませる：チャットは流れて消えます。チケットなど、後から追跡できる場所に残すことが必要です。
公表時期の話を現場でする：公表時期の調整は窓口の担当者が行うべきで、FDEが個人として約束しないほうが安全です。

FDEとしてのキャリアを考えると、「技術的に直せる」ことに加えて、「正しい経路に乗せられる」ことも顧客からの信頼につながる評価軸です。SWEやITコンサルとの違いは、顧客の運用と自社のプロダクトの両方の窓口をつなぐ役割を担う点にあります。FDE導入を検討している企業は、契約の段階で「現場で脆弱性を見つけた場合の報告先と、報告に含めてよい情報の範囲」を合意しておくと、現場の担当者が迷わずに済みます。