bug bounty とは
注：この文書は英語の原文からの自動翻訳です。
bug bounty とは
bug bounty（バグバウンティ）とは、プロジェクトが自社コードの脆弱性を発見し、責任ある形で開示してくれた独立系セキュリティ研究者に金銭的報酬を提供するプログラムです。社内チームや雇った監査人だけに頼るのではなく、bug bounty はバグの探索をグローバルなセキュリティコミュニティに開放します — スキルのある人なら誰でも参加でき、プロジェクトは有効な脆弱性が見つかったときにのみ報酬を支払います。
bug bounty は、建物のすべての鍵を試してもらうために大勢の錠前職人を雇い、「ピッキングできる鍵を見つけた人には報酬を支払う」という常設の申し出をするようなものだと考えてください。本当の欠陥が見つからない限り支払いは発生せず、報酬は発見の深刻度に比例するため、職人たちはより熱心に探す動機を持ちます。暗号資産においては、同じ原理がスマートコントラクトのコード、プロトコルのロジック、インフラのセキュリティに適用されます。
要約： bug bounty は、脆弱性を見つけて報告した独立系研究者に報酬を支払うクラウドソース型のセキュリティプログラムであり、構造化された 監査 を補完する、継続的でオープンエンドなセキュリティカバレッジを提供します。
bug bounty の仕組み
プログラムの構成
bug bounty プログラムはいくつかの重要な要素を定義します：
- Scope（スコープ） — どのコントラクト、コードリポジトリ、フロントエンド、API、インフラコンポーネントが提出対象となるか。スコープ外の項目は明示的に除外され、無駄な労力や誤った報告を防ぎます。
- Severity tiers（深刻度の階層） — 脆弱性は影響度によって分類され、通常は Critical、High、Medium、Low といった尺度が使われます。各階層には定義された報酬範囲があります。
- Reward amounts（報酬額） — 支払いは、低深刻度の発見に対する数百ドルから、ユーザー資金の損失につながりうる重大な脆弱性に対する数十万ドル（あるいはそれ以上）に及びます。一部の大手 DeFi プロトコルは、重大なバグに対して 100 万ドルを超える報酬を提供しています。
- Rules of engagement（参加ルール） — 研究者は責任ある開示の慣行に従わなければなりません：非公開で報告する、脆弱性を悪用しない、修正がデプロイされる前に公開しない、実ユーザー資金を伴う mainnet 上でテストしない。これらのルールに違反すると、通常は提出が無効となります。
提出とトリアージ
研究者は潜在的な脆弱性を発見すると、bug bounty プラットフォームを通じて、またはプロジェクトに直接、詳細な報告を提出します。報告には、脆弱性の説明、エクスプロイトを実証する概念実証（proof of concept）、推定される影響、該当する場合は推奨される修正が含まれます。
プロジェクトのセキュリティチーム（または bug bounty プラットフォームのトリアージチーム）が提出内容をレビューし、発見を検証し、深刻度を評価し、適切な報酬を決定します。このプロセスは、問題の複雑さに応じて数日から数週間かかることがあります。脆弱性が確認・修正されると、研究者は報酬を受け取り、その発見は（研究者の同意を得て）コミュニティの信頼と知識を築くために公開されることがあります。
bug bounty プラットフォーム
ブロックチェーンプロジェクトの bug bounty プログラムを管理することに特化したプラットフォームがいくつか存在します：
- Immunefi — DeFi およびブロックチェーンの bug bounty における支配的なプラットフォームで、業界最大級の報酬プールを持つ主要プロトコルのプログラムをホストしています。
- HackerOne と Bugcrowd — 一部の暗号資産プロジェクト、特に Web アプリケーションやインフラのセキュリティで利用される汎用の bug bounty プラットフォームです。
これらのプラットフォームは、提出管理、トリアージ支援、支払い処理を担い、研究者とプロジェクトの間の信頼レイヤーを提供します。また、研究者向けの公開リーダーボードやレピュテーションシステムも維持しています。
crypto AI プロジェクトにとって bug bounty が重要な理由
継続的なセキュリティカバレッジ
スマートコントラクトの 監査 は、ある特定の時点でのレビューです — それは特定の瞬間に存在するコードを検査します。監査後にコードが変更されたり、新しいコントラクトがデプロイされたり、プロトコルが新しい外部システムと相互作用したりすることがあります。bug bounty は継続的なセキュリティカバレッジを提供します：プログラムが有効である限り、世界中の研究者が現在稼働中のバージョンのコードに含まれる脆弱性を見つける動機を持ちます。
多様な専門知識
単一の監査チームがすべての可能な攻撃ベクトルをカバーすることはできません。bug bounty プログラムは、多様な経歴、専門分野、視点を持つ研究者を引き寄せます。reentrancy 攻撃を専門とする者、経済的エクスプロイトを専門とする者、クロスチェーンブリッジの脆弱性を専門とする者、オフチェーンインフラを専門とする者などがいます。この専門知識の多様性は、単一の監査チームが見逃すかもしれない脆弱性を発見する確率を高めます。
インセンティブの一致
bug bounty は、研究者が脆弱性を悪用するのではなく報告するための金銭的インセンティブを生み出します。bug bounty がない場合、重大な欠陥を発見した研究者は選択を迫られます：無償で（よくても小さな謝礼で）報告するか、それを悪用して大きな金銭的利益を得る可能性があるか。十分な資金のある bug bounty は、責任ある開示をより有利な選択肢にすることで、この計算を変えます。
セキュリティへのコミットメントのシグナル
DecAIHub に掲載されているプロジェクトにとって、意味のある報酬額を備えたアクティブな bug bounty プログラムは、チームがセキュリティを一度きりのチェックボックスではなく継続的な関心事として扱っていることを示すシグナルです。完了した監査とアクティブな bug bounty の両方を持つプロジェクトは、セキュリティへの多層的なアプローチ — スマートコントラクトベースのシステムで利用できる最も成熟した態勢 — を示しています。
DecAIHub のプロジェクトカードでどこに現れるか
Bug bountyフィールド (yes/no/—) — プロジェクトがアクティブな bug bounty プログラムを維持しているかどうかを示します。プログラム、プラットフォーム（Immunefi、HackerOne など）、規約へのリンクはlinks_*フィールドおよび／または Evidence 表に入ります。- Evidence：
Bug bounty— アクティブなプログラムの存在とそれへのリンクを記録する、エビデンス表の行です。 Security and incidentsセクション — bug bounty のステータス、監査、プロジェクトの脅威モデルを記載するカードの部分です。
実質的な報酬を伴うアクティブなプログラムは、支払いが最小限のプログラムやプログラムが全くない場合よりも強いセキュリティシグナルです。監査ステータスと bug bounty ステータスの組み合わせは、プロジェクトのオンチェーンインフラの全体的なセキュリティ成熟度を評価するのに役立ちます：どちらもないプロジェクトはより高いリスクを表し、両方を持つプロジェクトは最も成熟したセキュリティ態勢を表します。
bug bounty だけでは証明できないこと
- 脆弱性の不在 — bug bounty は研究者がバグを見つける動機付けをしますが、報告された発見がないことはコードが安全であることを証明しません。それは、誰も十分に詳しく調べていない、スコープが狭すぎる、または報酬がトップ研究者を引き寄せるには不十分であることを意味するかもしれません。
- コード品質 — bug bounty はリアクティブな（事後対応的な）仕組みです。バグが存在した後に捕捉しますが、それを生み出した開発プロセスを改善するわけではありません。クリーンなコード、徹底したテスト、健全なアーキテクチャは別の問題です。
- オンチェーンセキュリティのみ — ほとんどの bug bounty プログラムはスマートコントラクトおよびプロトコルレベルの脆弱性に焦点を当てています。オフチェーンインフラ、フロントエンドアプリケーション、API サーバー、AI 推論パイプラインはカバーしないことがあります。実際に何がカバーされるかはスコープの定義によって決まります。
- 公正な報酬分配 — 深刻度の分類や報酬額をめぐる研究者とプロジェクトの間の紛争は実際に起こります。すべてのプログラムが公正に運営されているわけではありません。プラットフォームのレピュテーションと、提出物を扱うプロジェクトの実績が重要です。
- 分散化やガバナンスの質 — bug bounty はセキュリティの仕組みであって、ガバナンス構造ではありません。強力な bug bounty プログラムを持つプロジェクトでも、完全に中央集権的な統制、不透明なガバナンス、集中した admin keys を持つことはあり得ます。
混同しないでください
| 用語 | 区別 |
|---|---|
| 監査 | 監査は、選ばれたチームによる構造化され期間が区切られたコードレビューです。bug bounty は、誰でも脆弱性を見つけられるオープンで継続的な招待です。監査はプロアクティブで、bug bounty はリアクティブかつ継続的です。両者は互いに補完し合います。 |
| 責任ある開示（Responsible disclosure） | 責任ある開示とは、脆弱性を公表する前に、影響を受ける当事者へ非公開で報告する慣行です。bug bounty は、金銭的報酬によって責任ある開示を動機付けるプログラムです。すべての責任ある開示が bug bounty を通じて行われるわけではありません。 |
| Bounty program（非セキュリティ） | 一部のプロジェクトは、セキュリティ以外のタスク — ドキュメント、翻訳、コミュニティ構築 — に対して bounty を提供します。bug bounty は、コードとインフラのセキュリティ脆弱性を具体的に対象とします。「bounty」という語だけでは曖昧になり得ます。 |
よくある質問
bug bounty は監査とどう違いますか？
監査 は、選ばれたセキュリティ専門家チームがコードを体系的にレビューし、包括的なレポートを作成する、構造化され期間が区切られた取り組みです。bug bounty は、資格のある研究者なら誰でも脆弱性を見つけて報告できるオープンで継続的な招待です。監査はプロアクティブで計画的、bug bounty はリアクティブで継続的です。両者は異なる目的に役立ち、一緒に使われたときに最も効果的です。
bug bounty プログラムを効果的にするものは何ですか？
効果を決める要因は三つあります：scope（プログラムは最も重要なコンポーネントをカバーしなければなりません）、rewards（報酬は熟練した研究者 — 特に重大度の発見について — を引き寄せるのに十分な大きさでなければなりません）、responsiveness（プロジェクトは提出物を迅速にトリアージし、透明にコミュニケーションし、公正に支払わなければなりません）。報酬が低く、スコープが狭く、トリアージの評判が悪いプログラムは、真剣な研究者を引き寄せるのに苦労します。
誰でも bug bounty に参加できますか？
一般的には、はい。ほとんどのブロックチェーン bug bounty プログラムは、脆弱性を特定する技術的スキルを持つ人なら誰にでも開かれています。研究者は正式な資格や所属を必要としません — 重要なのは提出物の質です。ただし、参加者はプログラムのルールに従わなければなりません：責任ある開示、脆弱性を悪用しないこと、実ユーザー資金を伴う mainnet 上でテストしないこと。制裁対象の個人や団体は、法令順守の理由で除外されることがあります。
外部リンク
- Immunefi — Bug Bounty Platform — DeFi およびブロックチェーンプロジェクト向けの主要な bug bounty プラットフォームで、業界最大級の報酬プールを持つプログラムをホストしています。
No comments to display
No comments to display