バグバウンティとは？報奨金の決め方・運用の流れ・監査との違いを解説

自社では見つけられなかった脆弱性を、外部のセキュリティ研究者に発見してもらい、報奨金を支払う。この仕組みがバグバウンティです。攻撃者に先を越される前に穴を塞ぐ手段として、Web業界からブロックチェーン領域まで広く導入が進んでいます。

本記事では、バグバウンティの仕組みと報奨金の考え方、運用の流れを解説したうえで、スマートコントラクト特有の事情と、セキュリティ監査との使い分けを実運用の経験をもとに整理します。

バグバウンティとは ― 脆弱性の発見に報奨金を払う制度

バグバウンティとは、自社のシステムやサービスの脆弱性を発見・報告してくれた外部のセキュリティ研究者に、報奨金を支払う制度です。攻撃者より先に脆弱性を見つけてもらうことで、実被害を未然に防ぎます。

バグバウンティの定義と仕組み

バグバウンティは、対象範囲とルールを公開し、脆弱性の報告を広く受け付ける仕組みです。報告を受けた企業は内容を検証し、脆弱性として認められれば深刻度に応じた報奨金を支払います。

最大の特徴は、成果報酬型である点です。発見された脆弱性に対してのみ支払いが発生するため、多数の研究者が継続的に調査・報告できる環境を設けながら、コストは成果に連動します。また、社内では気づけない多様な視点と攻撃手法が持ち込まれる点も、内部のレビューでは代替しにくい価値です。

報告する側は、脆弱性を悪用せず正規の手続きで報告する研究者、いわゆるホワイトハッカーです。企業側がルールと報奨金を明示することで、彼らが安心して調査・報告できる環境を用意する。この関係性を制度として成立させたものが、バグバウンティだと言えます。

セキュリティ監査・ペネトレーションテストとの違い

混同されやすい3つの手法は、目的と時間軸が異なります。

監査は「その時点の状態」を、定められた範囲で専門家が集中的に検査するもので、リリース前の品質保証に向いています。対してバグバウンティは、時間の経過とともに現れる新しい攻撃手法や、監査では見落とされた穴を継続的に拾い上げる仕組みです。どちらかを選ぶものではなく、役割が異なる手段として組み合わせて使います。

なぜ企業がバグバウンティを導入するのか

導入の動機は大きく3つあります。

1. 社内やベンダーだけでは得られない多様な視点を確保できる
2. リリース後も継続的に脆弱性を検出できる
3. コストが成果に連動する構造にある

特にブロックチェーン領域では、脆弱性が直接的な資産流出につながるため、導入の必要性が高まっています。実際に、代表的なバグバウンティ運営プラットフォームでは、単一の報告に対して100万ドル規模の報奨金を設定するプロジェクトも珍しくありません。

導入の判断で見落とされやすいのが、実施しない場合のコストです。脆弱性を突かれた場合の被害額は、資産の流出だけでなく、信頼の失墜による事業機会の損失にも及びます。報奨金は「発見してもらうための費用」ではなく、「被害を未然に防ぐための保険」として捉えると、投資判断がしやすくなります。

報奨金の決め方 ― 「攻撃するより報告した方が得」を設計する

報奨金設計の大原則は、脆弱性を見つけた人に「攻撃に悪用するより、報告した方が得だ」と思わせることです。この原則から逆算すると、深刻な脆弱性ほど高額の報奨金を設定する合理性が見えてきます。

報奨金設計の大原則

実運用の現場で共有されている原則は明確です。その脆弱性を突いて攻撃するより、報告した方が得だと思ってもらわなければならない、ということです。裏を返せば、報奨金が低すぎるプログラムは、発見者が正規の手順で報告するインセンティブを弱めてしまいます。

極端に言えば、攻撃すれば預かり資産の大半を流出させられるような脆弱性が見つかった場合、バグバウンティの報奨金を全額支払っても過言ではありません。守られた資産の規模と比べれば、報奨金は十分に合理的なコストだからです。この考え方は、主要なバグバウンティプラットフォームの規定にも表れており、深刻な脆弱性については「研究者が報告を控えることを防ぐため」として最低報酬額が定められています。

影響度のランク分けと金額設定

実務では、脆弱性の影響度をランク分けし、「このクラスの脆弱性であればいくら支払う」という形で金額を設定します。深刻度の区分は、資産の流出に直結するCritical（重大）から、実害の限定的なLow（軽微）まで、4段階程度に分けるのが一般的です。

Critical（重大）：預かり資産の直接的な流出、資産の恒久的な凍結など、事業の根幹に関わる影響。

High（高）：一部の資産や報酬の流出、一時的な機能停止など、限定的だが実害のある影響。

Medium・Low（中・低）：条件が揃った場合のみ成立する問題や、実害が軽微な不具合。

スマートコントラクトの領域では、影響を受ける資産額に連動させる方式が広く採用されています。例えば、重大な脆弱性については「直接影響を受ける資産の10%を、上限額の範囲で支払う」といった規定を設け、あわせて最低保証額を定めます。報告の価値が実被害の規模と釣り合う設計です。

報奨金の相場感

金額はプロジェクトの規模と預かり資産の大きさによって大きく変わります。ブロックチェーン領域の主要プラットフォームで公開されているプログラムを見ると、重大な脆弱性の上限額は数万ドル規模から、大規模なプロジェクトでは1,000万ドル規模まで幅があります。最低保証額も数千ドルから10万ドル超まで、プロジェクトによって大きく異なります。

過去には、重大な脆弱性の報告に対して1,000万ドルが支払われた事例もあります。自社の預かり資産や被害想定額から逆算し、「攻撃するより報告した方が得」が成立する水準を設定することが、金額決定の基準になります。

逆に、預かり資産に対して報奨金が明らかに低い設定は、プログラムを形骸化させます。研究者から見て調査に投じる時間に見合わなければ、そもそも報告が集まりません。「実施している」という体裁だけが残り、脆弱性は放置されるという最悪の状態を避けるためにも、金額は実態に即して設定する必要があります。

バグバウンティの運用フロー

バグバウンティの運用は、対象範囲とルールを定めるプログラム設計から始まり、報告の受付・検証・修正・支払いという流れで進みます。運用で最ももめやすいのが、同じ脆弱性が複数報告される「重複報告」の扱いです。

プログラム設計 ― 対象範囲・ルール・除外条件

最初に決めるのが、どこまでを対象とするかです。対象となるシステム・コントラクトアドレス・ドメインを明示し、あわせて対象外の範囲も定義します。本番環境への攻撃的なテストの禁止、他のユーザーへの影響を伴う検証の禁止など、研究者が守るべきルールも事前に明文化します。

除外条件の設定も重要です。既知の問題、実害につながらない指摘、外部サービスに起因する事象などをあらかじめ対象外としておかないと、判定に時間を取られ、報告者との認識のずれも生じます。

報告の受付から修正・支払いまで

運用の流れは、報告の受付、内容の検証（トリアージ）、深刻度の判定、修正、報奨金の支払い、という順序です。特に重要なのが、受付から一次回答までの応答速度です。回答が遅れると、報告者は「対応されていない」と判断し、公開に踏み切る可能性があります。

修正が完了するまでの間、脆弱性を非公開に保つ期間（開示ポリシー）も事前に合意しておきます。修正後に報告内容を公開するか、公開する場合の時期と範囲をルール化しておくことで、後のトラブルを防げます。

あわせて、報告を検証する社内体制も準備が必要です。報告の多くは実害のない指摘や既知の問題であり、これらを切り分ける一次対応の負荷は想像以上に大きくなります。誰が検証し、深刻度を誰が判定し、支払いを誰が承認するか。この役割分担を決めないまま開始すると、報告が滞留して応答が遅れる原因になります。

運用でもめやすい「重複報告」の判定

実運用で最も判定が難しいのが、重複報告の扱いです。実際に起きた事例として、運営側が先に気づいて修正していた脆弱性について、後から外部の研究者による指摘が入ったケースがあります。

このとき「すでに修正済みなので報酬は支払えない」と回答したところ、報告者との間でもめる事態になりました。結果的には5 ETHを支払って決着しています。当時のレートでは10万円ほどでしたが、暗号資産の価格変動を考えれば、同じ数量でも支払い時点によって負担は大きく変わります。判定基準が曖昧なまま運用を始めると、金額の大きさに関わらず信頼を損なうリスクがあります。

この経験から言えるのは、重複報告の判定基準を事前に整備しておく必要性です。「社内で認識していた」ことをどう証明するか、修正済みの脆弱性への報告をどう扱うか、同時期の複数報告の優先順位をどうつけるか。これらをプログラム開始前にルール化し、公開しておくことが、後のトラブルを最小化します。

スマートコントラクトのバグバウンティ ― 監査との使い分け

スマートコントラクトのコードは、原則としてデプロイ後に変更できません。アップグレード可能な設計を事前に組み込む方法はありますが、それ自体にトレードオフを伴います。この特性ゆえに、リリース前の監査と、長期にわたるバグバウンティを組み合わせた多層的なセキュリティ設計が不可欠になります。

デプロイ後に修正できないからこそのセキュリティ設計

一般的なWebサービスであれば、脆弱性が見つかっても修正版をデプロイし直せば対応できます。しかしスマートコントラクトは、ブロックチェーン上に一度公開したコードを後から書き換えることが原則としてできません。脆弱性が残ったまま資産を預けてしまった場合、攻撃者に発見・悪用されれば、短時間で資産流出につながる可能性があります 。

この不可逆性が、セキュリティ対策の設計思想を変えます。「リリース後に直せばよい」という前提が使えないため、公開前にどれだけ穴を潰せるかが決定的に重要になります。同時に、公開後も継続的に監視し続ける体制が求められます。

なお、アップグレード可能な設計や緊急停止機能を組み込むことで、事後対応の余地を残す手法もあります。ただしこれらは、運営者が強い権限を持つことを意味し、分散性や利用者からの信頼とのトレードオフになります。どこまで事後対応の余地を残すかは、セキュリティ設計と同時に検討すべき論点です。

関連記事：コントラクト設計と並んで重要な秘密鍵の管理手法については「秘密鍵管理にMPCが必要な理由とは？」で詳しく解説しています。

監査はリリース前、バグバウンティは長期 ― 実運用の使い分け

実運用の現場では、次のような使い分けが採られています。監査はサービス公開前に実施し、バグバウンティは監査の前からリリース後まで含めた広い期間で継続するという考え方です。

具体的な流れとしては、まず監査の前にプロトタイプ版を世に出し、その段階でバグバウンティを実施します。そこで見つかった穴を潰し、なるべく綺麗な状態にしたものを監査にかけます。監査はその時点の状態にしか実施できないため、穴が残ったまま監査を受けるのは費用対効果が悪いからです。

そしてリリース後は、「何か穴があったら教えてください」という長期的なバグバウンティに移行します。監査はリリース前の一点、バグバウンティは長期の面。この役割分担が、実運用で採られている使い分けの一例です。

なお、実施の順序は一通りではありません。監査を先に受けてからテストネット段階でコンテスト形式の検証を行い、その後リリース後のバグバウンティへ移行する進め方もあります。重要なのは順序そのものよりも、監査という一時点の検査と、バグバウンティという継続的な検出を、デプロイ前後にわたって組み合わせることです。

実例 ― 「金庫なのに抜ける」バグを公開前に発見できた理由

実際にこの流れで重大な脆弱性が発見された例があります。ベスティング（分配）プラットフォームの開発で、イーサリアムをコントラクト上に預け入れ、毎月少しずつ受け取れるようにする、いわば金庫のような仕組みを構築したケースです。

この金庫自体に、預けた資産が抜き取られてしまう穴がありました。資産を守るための金庫なのに、その金庫から資産が抜けてしまうという、機能の根幹を揺るがす脆弱性です。もし本番リリース後に攻撃されていれば、預かった資産が流出していた可能性があります。

この脆弱性が見つかったのは、リリース前、それも監査より前に実施したバグバウンティの段階でした。まさに脆弱性を見つけてもらうことを目的に実施したフェーズであり、危険な事態には至っていません。公開前にバグバウンティを組み込む設計が機能した実例と言えます。

バグバウンティに関するよくある質問

バグバウンティの導入検討時によく寄せられる質問とその回答をまとめました。

小規模なプロジェクトでも実施すべきですか？

預かり資産がある場合は、規模にかかわらず検討すべきです。スマートコントラクトは原則としてデプロイ後にコードを変更できないため、小規模でも脆弱性の影響は資産の全額に及ぶ可能性があります。予算が限られる場合は、報奨金の上限を自社の預かり資産に見合う水準に設定し、対象範囲を中核のコントラクトに絞ることで、現実的な規模から始められます。

費用はどのくらいかかりますか？

報奨金は成果報酬のため、脆弱性が報告されなければ支払いは発生しません。一方で、プログラム設計、報告の検証体制、運営プラットフォームの利用料など、運用側のコストは固定的に発生します。報奨金の総額は、預かり資産と設定する上限額から逆算して見積もります。監査費用とあわせ、セキュリティ全体の予算として計画することを推奨します。

関連記事：ブロックチェーン開発全体のコスト感については「ブロックチェーン開発の費用・コストを解説」で解説しています。

監査を受けていればバグバウンティは不要ですか？

不要にはなりません。監査は依頼した時点のコードを、定めたスコープの範囲で検査するものであり、その後の仕様変更や、監査時には知られていなかった攻撃手法には対応できません。実運用では、監査前にバグバウンティで穴を潰してから監査にかけ、リリース後も継続的にバグバウンティを回すという進め方が採られています。両者は代替関係ではなく、時間軸の異なる補完関係にあります。

報告者に脆弱性を悪用されるリスクはありませんか？

ゼロにはできませんが、設計で大きく下げられます。基本は報奨金の水準を「攻撃するより報告した方が得」が成立する額に設定することです。あわせて、テスト環境の提供、禁止行為の明文化、報告者との合意形成を行うことで、悪用の動機と機会の双方を減らせます。プラットフォームやプログラムによっては、研究者の本人確認や紛争時の仲裁制度を利用できる場合もあります。導入時には、これらの設定条件を確認したうえで運用方法を選定してください。

まとめ

バグバウンティは、外部のセキュリティ研究者に脆弱性を発見してもらい、報奨金を支払う成果報酬型の制度です。報奨金設計の原則は「攻撃するより報告した方が得」と思わせることであり、影響度に応じたランク分けと、被害想定額から逆算した金額設定が基本になります。

運用面では、重複報告の判定基準を事前に整備しておくことが、トラブル回避の鍵です。そしてスマートコントラクトでは、デプロイ後にコードを原則として変更できず、アップグレード可能な設計にも固有のリスクが伴うことから、監査という一時点の検査と、バグバウンティという継続的な検出を組み合わせる設計が欠かせません。実運用では、監査前の段階からバグバウンティを始め、リリース後も長期にわたって継続する進め方が採られています。

XTELAでは、スマートコントラクトの開発から、バグバウンティの設計・運用、監査前のセキュリティ検証までを支援しています。「自社のプロジェクトで何をどこまで実施すべきか」の整理段階から、お気軽にご相談ください。