ホワイトハッカーとは？ハッカーとの違いや活用事例について紹介|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2025年03月11日更新日時: 2026年08月02日

ホワイトハッカーという言葉は、今でも善玉のハッカーという説明で済まされがちです。ただ、情報システム部門の立場で見ると、それだけでは少し足りません。いま海外の政府機関や大手テック企業が進めているのは、腕のいい個人に脆弱性を見つけてもらうことではなく、外部の研究者からの報告を安全に受け取り、優先度を付け、修正し、再発防止へつなげる仕組み作りです。

社内の脆弱性診断やペネトレーションテストだけでは、公開後のサービス、連携先、クラウド設定、API、モバイルアプリ、AI機能まで見切れない場面が増えています。そこで、ホワイトハッカーを組織の外側にいる攻撃者視点の協力者としてどう受け入れるかが、企業のセキュリティ成熟度を分ける要素になりつつあります。

ホワイトハッカーとは？海外公的機関や企業の活用事例から見る必要性と導入方法のサマリー

ホワイトハッカーとは、許可された範囲で脆弱性を調査し、悪用ではなく修正と防御に役立てるセキュリティ研究者や専門家を指します。
米国防総省は2016年に連邦政府初のバグバウンティであるHack the Pentagonを実施し、138件の有効な脆弱性を確認しました。
CISAは米連邦政府機関に対して脆弱性開示ポリシーの策定を求め、NISTも脆弱性報告を受け付け、評価し、修正する枠組みを示しています。
英国NCSCは政府オンラインサービス向けの脆弱性報告窓口やVDP Toolkitを提供し、security.txtや安全な連絡手段の整備を推奨しています。
Google、Microsoft、Apple、Metaなどは、バグバウンティや研究者向けプログラムを通じて、AI、クラウド、ブラウザ、モバイル、ハードウェアまで対象を広げています。
日本企業がホワイトハッカーを活用するには、報奨金の有無よりも、対象範囲、禁止行為、連絡窓口、修正判断、研究者への返信体制を先に決めることが重要です。

ホワイトハッカー活用事例の整理表

区分	主な取り組み	企業・組織への示唆
米国防総省	Hack the PentagonとDoD VDPを通じ、外部研究者から脆弱性報告を受け付け	機密組織でも、対象範囲とルールを切れば外部研究者を活用できる
CISA・NIST	連邦政府機関向けにVDPや脆弱性開示フレームワークを整備	脆弱性報告受付は善意への対応ではなく、組織的なリスク管理として扱う
英国NCSC	UK政府サービス向け報告窓口、Disclosure for Government Scheme、VDP Toolkitを提供	報告先を分かりやすくし、security.txtなどで研究者が迷わない導線を作る
欧州委員会・ENISA	CVD、EU-FOSSA、EUVDなどを通じて脆弱性調整とOSS安全性向上を推進	自社製品だけでなく、利用するOSSやサプライチェーンも対象に含める
Google	2025年のVRPで1,700万ドル超を700名以上の研究者に支払い、AI VRPも専用化	外部研究者は新領域の安全性確認にも使える。AI機能も例外ではない
Microsoft	2025年に3億ドルではなく1,700万ドルを344名の研究者へ支払い、Copilotやクラウド領域も対象化	クラウド、ID、AIなど高影響領域を重点的に見てもらう設計が必要
Apple	Apple Security Bountyを拡充し、スパイウェア級攻撃チェーンに最大200万ドル、ボーナス込みで500万ドル超を提示	攻撃難度が高い領域ほど、専門研究者との継続的な関係が重要になる
Meta	2024年に約1万件の報告を受け、約600件の有効報告に支払い	報告量が増える前提で、トリアージ体制と対象範囲の明確化が欠かせない

ホワイトハッカーは善意の個人ではなく制度として受け入れる段階に入った

ホワイトハッカーは、企業や公的機関のシステムに潜む弱点を発見し、適切な窓口へ報告する人たちです。攻撃者と同じような視点でシステムを見るため、開発者や運用担当者が見落とした実装ミス、認可制御の不備、APIの設計上の穴、クラウド設定の抜けを見つけることがあります。

ただし、ホワイトハッカーと呼べるかどうかは、技術力の高さだけでは決まりません。許可された範囲で調査すること、取得するデータを最小限に抑えること、発見した問題を勝手に公開しないこと、修正に必要な情報を責任ある形で提供することが前提になります。この点を曖昧にしたまま、自由に調べてくださいという姿勢を取ると、企業側も研究者側も危ない立場に置かれます。

昔は、脆弱性を見つけた人が企業へ連絡しても返事がない、逆に不正アクセス扱いされる、といった話が少なくありませんでした。セキュリティ対策Labの既報でも、猫型配膳ロボット(BellaBot)で遠隔操作可能な脆弱性-メーカーへ報告後も無視される事例を取り上げています。ここで見えてくるのは、研究者の善意だけに頼るのではなく、企業側が受け皿を用意しておく必要性です。

ホワイトハッカーとブラックハッカーの違いは許可と責任の設計にある

ホワイトハッカーとブラックハッカーの違いを、善意か悪意かだけで分けると実務では危うくなります。企業側が見るべきなのは、許可、範囲、報告、データ取扱い、公開の5点です。

許可があるかどうかは最も分かりやすい違いです。許可なく本番環境へアクセスし、データを抜き取り、外部へ公開すれば、目的が防御だったとしても企業や利用者に損害を与える可能性があります。ホワイトハッカーの活動は、事前に決められた対象範囲やルールの中で行われる必要があります。

範囲も重要です。たとえばWebサイトは調査対象でも、従業員へのフィッシング、物理侵入、DDoS、顧客データの大量取得は対象外にする、といった線引きが必要になります。この線引きがなければ、研究者はどこまで許されるのか判断できません。企業側も、報告を受けた後に法務、広報、開発、CSIRTがどう動くか決められません。

その意味で、ホワイトハッカー活用は単なるバグ探しではありません。脆弱性とは？で解説しているように、脆弱性はシステム上の弱点です。その弱点を誰が、どの経路で、どの順番で修正へつなげるのかまで設計して初めて、企業のリスク低減に結びつきます。

米国防総省はホワイトハッカー活用を安全保障の仕組みにした

海外公的機関の代表例が、米国防総省のHack the Pentagonです。2016年に実施されたこの取り組みは、米連邦政府初のバグバウンティとして位置付けられました。対象は公開Webサイトに限定され、1,400名以上の適格なハッカーが招待され、250名以上が少なくとも1件の脆弱性報告を提出しました。そのうち138件が有効かつ重複のない報奨対象として認められています。

注目すべきなのは、国防総省が外部研究者に何でも自由に触らせたわけではない点です。対象は5つの公開Webサイトに絞られ、重要ネットワークは対象外でした。外部研究者の力を使いつつ、調査範囲を限定し、HackerOneのようなプラットフォームを使って報告と支払いを管理しています。

この考え方は、民間企業にもそのまま当てはまります。最初から全社システムを対象にする必要はありません。コーポレートサイト、採用サイト、公開API、テスト用サービス、影響の限定されたWebアプリから始めるだけでも、攻撃者より先に弱点を知る機会になります。

米国防総省はその後、DoD Vulnerability Disclosure Programを通じて、研究者との継続的な報告受付体制を整えました。2021年には対象を公開Webサイトから公開アクセス可能な情報システム全体へ広げています。ここから分かるのは、バグバウンティは単発イベントで終わらせるものではなく、脆弱性管理の運用プロセスへ組み込むものだという点です。

CISAやNISTは脆弱性報告を受ける体制そのものを標準化している

米国では、CISAがBinding Operational Directive 20-01を通じて、連邦文民行政機関にインターネット公開システム向けの脆弱性開示ポリシーを策定し、公開することを求めています。報告を受け付ける窓口がなければ、外部研究者はどこに知らせればよいか分かりません。企業側も、せっかくの報告をセキュリティ部門へ届けられず、問い合わせ窓口やSNS担当で止まってしまうことがあります。

NIST SP 800-216も、脆弱性報告を受け付け、評価し、修正し、コミュニケーションを行うための連邦向けガイドラインを示しています。ここで重要なのは、脆弱性報告を単なる問い合わせ処理として見ないことです。報告には、再現条件、影響範囲、修正優先度、暫定対策、公開タイミング、関係者への通知が絡みます。これは情報システム部門、開発部門、法務、広報、経営が連携するインシデント対応に近い仕事です。

2026年7月には、NSA、CISA、JPCERT/CC、オランダNCSCなどが、外部セキュリティ研究者と協力するためのCVDプログラム構築に関する共同ガイダンスを公表しています。日本のJPCERT/CCも関与している点は、国内企業にとって見逃せません。海外の話ではなく、日本企業が製品やサービスをグローバルに展開するうえでも、研究者とどう向き合うかが問われています。

英国NCSCは分かりやすい報告導線を重視している

英国NCSCは、政府オンラインサービスで脆弱性を見つけた人向けの報告窓口を用意しています。研究者には、まずサービス所有者へ連絡するよう求め、連絡先が見つからない場合や返事がない場合にはNCSCへ報告できる形です。HackerOneを使った報告導線も示され、報告後はトリアージチームが5営業日以内に評価する運用が説明されています。

NCSCのVDP Toolkitでは、脆弱性開示プロセスに必要な要素として、連絡手段、ポリシー、security.txtを挙げています。security.txtは、Webサイトの決まった場所に脆弱性報告先やポリシーを掲載するための仕組みです。研究者が報告先を探して迷う時間を減らすだけでなく、企業側にとっても報告の入口を一本化できます。

日本企業のWebサイトを見ると、脆弱性報告先が見つからないケースはまだ多くあります。お問い合わせフォームから送るしかない、脆弱性という単語を書くと営業問い合わせとして処理される、添付ファイルが送れない、暗号化手段がない、といった運用では、外部研究者との関係は作れません。報告先を用意することは、攻撃を呼び込む行為ではなく、すでに存在する弱点を早く知るための安全弁です。

欧州はOSSとサプライチェーンまで含めて考えている

欧州委員会は、脆弱性開示ポリシーを公開し、報告者に対して、必要以上のデータ取得を避けること、発見した脆弱性を解決前に公開しないこと、十分な再現情報を提供することなどを求めています。報告を受ける側も、3営業日以内に評価を返す、機密に扱う、可能な範囲で修正後に知らせる、といった約束を示しています。

EU-FOSSA 2では、欧州機関で利用される重要なオープンソースソフトウェアの監査やバグバウンティが行われ、15件のバグバウンティプログラムで200件の隠れたバグを発見し、倫理的ハッカーへ20万ユーロ超の報奨金を支払ったとされています。これは、自組織が作ったソフトウェアだけでなく、自組織が依存しているOSSにも目を向ける取り組みです。

セキュリティ対策Labでも、サプライチェーンリスクとは？インシデント事例から見る危険なポイントと対策を解説やサプライチェーン攻撃とは概要や攻撃手法と被害事例を解説で、外部委託先、OSS、更新機構、SaaS連携を起点にしたリスクを取り上げています。ホワイトハッカー活用も同じで、自社の本番環境だけで完結させると実効性が落ちます。利用中のOSS、公開API、外部連携、モバイルアプリ、クラウド権限まで視野に入れる必要があります。

GoogleやMicrosoftはAIやクラウド領域へバグバウンティを広げている

企業の活用事例として分かりやすいのがGoogleです。GoogleのVulnerability Reward Programは2010年に始まり、2025年には15周年を迎えました。Googleは2025年、700名以上の研究者に1,700万ドル超を支払い、累計では8,160万ドルに達したと公表しています。Chrome、Android、Google Cloudだけでなく、AI関連のVRPを専用化している点も重要です。

Microsoftも2025年、344名の研究者に1,700万ドルを支払ったと公表しています。対象はAzure、Microsoft 365、Dynamics 365、Power Platform、Windows、Edge、Xboxなど幅広く、Copilotやクラウドを対象にしたZero Day Questでは600件超の脆弱性提出と160万ドル超の支払いがありました。クラウド、ID、AIは、企業の業務基盤に直結する領域です。ここを外部研究者に見てもらうことは、単なるブランド向上策ではなく、顧客保護の一部といえます。

セキュリティ対策Labの既報でも、Google、Chromeのサンドボックス脱出の脆弱性発見者へ25万ドル（約3,675万円）の報奨を取り上げています。ブラウザのサンドボックス脱出のような高難度の脆弱性は、社内の通常テストだけで見つけきるのは難しい分野です。報奨金は研究者を動かす唯一の理由ではありませんが、難しい研究に時間を割いてもらう現実的なインセンティブになります。

AppleやMetaの事例から見えるホワイトハッカー活用の成熟

AppleはApple Security Bountyを拡充し、スパイウェア級の攻撃チェーンに最大200万ドル、Lockdown Mode回避やベータ版での発見などのボーナス込みで500万ドル超の可能性を示しています。2020年に一般公開して以降、800名以上の研究者へ3,500万ドル超を支払ったとも公表しています。

Appleの事例で特徴的なのは、単に報奨金を高くするだけでなく、Security Research Device Programのように、研究者がより深い領域を調査しやすい環境を用意している点です。高度な攻撃者が狙う領域ほど、外から見えるWebアプリ診断だけでは足りません。OS、デバイス、ブラウザ、クラウド連携、プライバシー機能まで含めた研究が必要になります。

Metaも2024年、約1万件の報告を受け、約600件の有効報告に対して支払い、約200名の研究者に230万ドル超を支払ったと公表しています。GenAI、AR/VR、広告ツール、ハードウェアなど、対象はWebアプリに限定されません。新しい事業領域を広げるほど、外部研究者に見てもらう範囲も広がっていきます。

ここで注意したいのは、大企業の報奨金額だけを真似ても意味がないことです。GoogleやMicrosoft、Apple、Metaが投資しているのは、報奨金だけではありません。対象範囲、研究者向けルール、専用ポータル、トリアージ、開発部門との連携、イベント、研究者コミュニティとの関係づくりまで含めた運用です。

ホワイトハッカー活用は脆弱性診断やペネトレーションテストと競合しない

情報システム部門では、ホワイトハッカー活用、脆弱性診断、ペネトレーションテスト、レッドチーム演習が混同されがちです。実際には、それぞれ役割が異なります。

脆弱性診断は、決められた対象に対して既知の弱点や設定不備を体系的に確認する取り組みです。ペネトレーションテストは、実際の攻撃手順に近い形で侵入可能性や権限昇格を検証します。レッドチーム演習は、組織の検知、対応、意思決定まで含めて試すことが多いです。セキュリティ評価サービス（SRS）とは？概要や種類、事例を解説でも触れている通り、外部から見た評価や継続的な可視化も重要になります。

一方、バグバウンティやVDPは、公開後のサービスを継続的に外部研究者が見る仕組みです。診断日だけ安全ならよいのではなく、リリース後の変更、API追加、設定変更、クラウド権限の変化まで含めて、発見の機会を増やす考え方です。

このため、ホワイトハッカー活用は診断の代替ではなく補完です。定期診断で基礎的な弱点を潰し、ペンテストで侵入シナリオを検証し、VDPやバグバウンティで外部からの継続的な発見を受ける。こうした組み合わせが、現実的な守り方になります。

バグバウンティ導入で失敗しやすいポイント

バグバウンティは、始めれば自動的に安全になる仕組みではありません。準備不足のまま公開すると、低品質な報告が大量に届き、現場が疲弊します。対象範囲が曖昧だと、研究者が調査してよい範囲を誤解し、企業側も報告を受けるたびに判断に迷います。

よくある失敗は、対象外の行為を明記していないことです。DDoS、ソーシャルエンジニアリング、物理侵入、顧客データの大量取得、従業員アカウントへの攻撃は、多くの企業では禁止すべきです。認証回避や個人情報閲覧の可能性を示す場合でも、どこまでのPoCを許すのかを決めておく必要があります。

返信体制も重要です。報告者は、脆弱性を見つけるまでに時間を使っています。企業から何週間も返事がない、重複や対象外の理由が説明されない、修正後の扱いが分からない、といった状態では、研究者コミュニティから信頼されません。報奨金を出さないVDPでも、受領確認、一次評価、修正方針、公開可否の連絡は必要です。

もう一つの課題は、修正できる体制がないまま報告だけを集めてしまうことです。脆弱性報告は、受け取った瞬間から管理責任が発生します。影響度を判断し、担当チームへ割り振り、期限を決め、修正後に再確認する流れがなければ、報告はリスク台帳に積み上がるだけです。

日本企業が取り入れるなら小さく始めるのが現実的

日本企業がいきなり大規模な公開バグバウンティを始める必要はありません。むしろ、最初はVDPから始める方が現実的です。VDPは、報奨金を前提としない脆弱性報告受付の仕組みです。報告先、対象範囲、禁止行為、対応目安、公開方針を示し、研究者が安全に報告できる状態を作ります。

最初に整備したいのは、専用メールアドレスかWebフォーム、security.txt、報告テンプレート、社内の一次受付フローです。問い合わせ窓口に届いた脆弱性報告をセキュリティ担当へ転送するだけでも、何もしないより大きく改善します。

次の段階で、対象を限定した招待制のバグバウンティを検討できます。新規リリース前のサービス、公開API、モバイルアプリ、キャンペーンサイト、クラウド管理画面など、影響範囲を絞りやすい対象から始めるとよいでしょう。対象が広すぎると、報告の質も量もコントロールしにくくなります。

社内規程も忘れてはいけません。外部研究者からの報告を不正アクセスとして扱うのか、善意の報告として扱うのかは、法務とセキュリティ部門であらかじめ合意しておく必要があります。もちろん、ルールを逸脱した行為まで許容する必要はありません。だからこそ、許される調査と禁止行為を明文化することが大切です。

情報システム部門への示唆

情報システム部門が最初に行うべきことは、自社が外部から脆弱性報告を受け取れる状態かを確認することです。Webサイト、サービス利用規約、セキュリティページ、問い合わせフォーム、security.txtを見直し、研究者が迷わず報告できる導線があるかを点検してください。

次に、報告後の社内フローを作ります。受付担当、一次評価担当、影響度判断、開発チームへの連携、修正期限、再現確認、報告者への返信、公開可否の判断を決めておく必要があります。これはCSIRTや開発部門だけでは完結しません。個人情報、広報、法務、事業責任者が関わる場面もあります。

バグバウンティを導入する場合は、対象範囲を小さく始めるべきです。最初から全サービスを対象にすると、対応できない報告量になる可能性があります。外部公開資産の棚卸し、脆弱性診断の実施、重要な既知脆弱性の解消を済ませたうえで、限定公開や招待制から始める方が安全です。

外部研究者との関係は、攻撃者に情報を渡す行為ではありません。むしろ、攻撃者にも見えている弱点を、先に防御側へ知らせてもらう仕組みです。海外の公的機関や大手企業がホワイトハッカーを活用しているのは、サイバー攻撃が高度化したからだけではなく、自組織だけで全ての弱点を見つけるのは現実的ではないと認めているからです。

日本企業にとって重要なのは、高額な報奨金を出すことではありません。脆弱性報告を歓迎する姿勢を示し、報告者を迷わせず、社内で確実に修正へつなげることです。そこまで整えて初めて、ホワイトハッカーは企業の外側にいるリスクではなく、セキュリティを強くする協力者になります。