オープンソーステスト： バグ報奨金プログラムを恐れるのではなく、受け入れるべき理由

オープンソースソフトウェアは、テスターや開発者としての私たちの仕事のやり方を変えた。以前よりもオープンソースのライブラリやパッケージを使用する機会が増えたため、私たちのチームがコントロールできない依存関係によってバグが発生する可能性がある。

そして今、私たちはオープンソースのテストの世界にも足を踏み入れている。オープンソースのプロジェクト（そして、多くのクローズドソースのプロジェクト）では、バグ報奨金プログラムを作成し、社外の人々に品質とセキュリティのプロセスに関与してもらうケースが増えているのだ 。

ブロックチェーンに基づくWeb3のエコシステムの重要性の高まりは、コミュニティのテストプログラムがいかに重要であるかを示しており、オープンソースのテスターによってバグが発見され、プロジェクトが数千万ドルを節約したという最近の例もある。

テスト・コミュニティーの中には、この傾向を脅威とみなす者もいる。しかし、実際にはチャンスである。バグ報奨金やオープンソースのテストへの貢献は、テストチームにとって素晴らしいツールであり、テスト担当者がこの新しいトレンドを恐れるのではなく、受け入れる理由は十分にある。

オープンソースソフトウェアのテストの課題

課題は2つある。ひとつは意思決定、もうひとつは統合だ。意思決定については、そのプロセスはプロジェクトによって実にさまざまだ。例えば、Rails（フレームワーク）のようなものであれば、リリースのタイムテーブルなどに合意する説明責任のあるグループがある。しかし、分散型エコシステムの中では、こうした決定はコミュニティがすることもある。例えば、DeFi（分散型金融）レンディングプロトコルは昨年、特定のバグを修正することに同意するためには、トークン保有者がその提案を承認する投票をしなければならない状況に陥った。

そのため、プロプライエタリ・ソフトウェアを製造している会社のように、特定のマネージャーやマネージャーのグループがリリースを担当するようなトップダウンのヒエラルキーはないかもしれない。

統合に関しては、たとえその製品自体がオープンソースでなくても、テスターにとってはしばしば問題となる。オープンソースのサードパーティのライブラリが更新されていないためにアプリケーションが壊れたり、ビルドスクリプトがテスト中のアプリケーションと互換性のない 新バージョンのパッケージを取り込んだりしても、SLA が適用されず、補償を請求するプロセスもないような、社外のボランティアによって書かれ、保守されているパッケージやモジュールが開発者に含まれる。データベースや API への接続を容易にするパッケージは、特に脆弱なポイントである。

バグ報奨金プログラムとその目的

バグ報奨金プログラムは、クラウドソーシングのテスト方法である。著者のJames Surowiecki氏は、著書『The Wisdom of Crowds（群衆の知恵）』の中で、特定の問題に目を向けている人が多ければ多いほど、正しい解決策を見つける可能性が高くなるという考え方を広めた。複数の依存関係や統合性を持つ非常に複雑なシステムの場合、たった一つの小さな抜け穴が何百万ドルもの損失を引き起こす可能性があるため、一人のテスターやテストチームが専門的な知識や予測能力を持ち、潜在的な問題をすべて特定できる可能性はますます低くなる。そのため、より広いコミュニティにバグを探すよう金銭的なインセンティブを与えることが、ますます一般的になってきている。

自分のウェブサイトに報酬表とともに条件を提供することで、バグ検索に金銭的なインセンティブを与えることができる。しかし、より一般的には、HackerOne、BugCrowd、ImmuneFiのようなプラットフォームが、あなたのためにプロセスを処理し、報酬を得るだけでなく、自分の能力を示すことに熱心なテスターやセキュリティ研究者にワンストップショップを提供する。

商用ソフトウェアの場合、プログラムの実施と特定の報酬の義務付けは、一元的に決定される。オープンソース、特にWeb3のエコシステム内では、そのプロセスは異なる。この場合、プロトコルを運営する財団やDAOは、バグ報奨金に資金を提供するために保有資産の一定割合を提供すること表明をする。

典型的な例としては、Compound（レンディングプロトコル）のバグ報奨金や、私がBoson Protocolボソンプロトコルの設立を手伝ったものがある。

ImmuneFiのCompoundバグ報奨金プログラムは、脆弱性の重大性に応じて得られる報奨金（最高5万ドル）が明確に示されており、また、特定のプルリクエストのみを含むように非常に明確にスコープが設定されているため、良い例だ。ImmuneFiは、報酬の支払いや紛争を処理する。

対照的に、Boson Protocolプログラムはすべてのスマートコントラクトを対象としており、懸賞金も同様に5万ドルだが、関連するウェブサイトやスマートコントラクト以外の資産は除外されている。この場合では、報奨金プログラムは仲介業者を介さず直接提供される。

オープンソースのバグ報奨金プログラムの利点と欠点

クローズドソースプロジェクトであっても、オープンソーステストの利点は、バグ捕捉の網の目を広げ、プロジェクトの正式採用されたテストチームにすべてのベースをカバーすることを依存するのではなく、はるかに多くの人々がシステムのセキュリティに貢献することを可能にすることだ。人気のあるオープンソースプロジェクトは、通常、中核となる開発チームによって保守され、その中にはテスターも含まれるかもしれないが、ほとんどのクローズドソースプロジェクトと同様に、彼らは、ソフトウェア開発ライフサイクルの中で時々必要とされる極めて専門的なスキルを持っていないかもしれない。 多くの企業は、例えば、侵入テストを行う専門サービスをすでに雇っている。バグ報奨金は一種の継続的な侵入テストと考えることができ、脆弱性を発見した場合にのみ、専門家の時間と専門知識に対する対価を支払うことになる。

しかし、何よりも、どんなプロジェクトであっても、クラウドソーシング・テストは、一人の人間やチームでは見つけることが不可能な、さまざまな異なるアプローチや考え方、スキルセットをもたらしてくれる。成功した製品やアプリケーションには、何万人、もしかしたら何百万人というユーザーがいて、その全員が異なる方法で使用し、異なるハードウェアを使って異なる経路を通るでしょう。より多くのスキルや意見にアクセスできることは、正しく活用すれば貴重な資源となる。

デメリットは主に、報奨金プログラムを関連スキルを持つ人たちにマーケティングするための余分な時間と労力にある。また、事前に報奨金の範囲を決めておかないと、企業や財団、プロジェクトが、テスターであるあなたがすでに発見したバグに対して報奨金を支払うことになるかもしれない。

Web3エコシステムのテスト

ブロックチェーン技術（Web3として知られることもある）は、多くの理由からテスターにとって非常に難しい分野である。主なものを2つ紹介しよう。

第一に、本番環境の状況をステージングで再現するのは非常に難しい。本番環境では、文字通り何千ものバリデータと何千ものユーザーが存在し、彼らはあなたが思いもよらない方法でシステムとやりとりするかもしれない。これは再現不可能だ。例えばビットコインのブロックチェーンを見てみると、本番のネットワークを完全に正確にシミュレーションするためには、電気代だけで文字通り何百万ドルもかかるだろう。

第二に、Web3システムはいわゆるレゴブロックのようにすべてのコンポーネントが組合せ可能なように設計されている。この簡単な例を挙げると、イーサリアム・ブロックチェーン用に考案されたERC20トークン標準は、ERC721 NFTトークン標準と同様に、どのウォレットにも移すことができる。つまり、開発者は分散型取引所でデリバティブを作成するスマート・コントラクトを作成し、そのデリバティブを使用して全く別の貯蓄プロトコルで収益を上げ、さらに別のプロトコルでその収益を担保として使用できる。このような相互依存関係は、特に重要なコンポーネントのひとつがうまくいかなかった場合、リスクを何倍にも膨れ上がらせる可能性がある。

こうしたオープンソースのプロトコルに文字通り数千万ドルが眠っているという事実もハニーポットとして稼働するようなリスクである。既存のバグ報奨金プログラムを見ると、提示される報奨金がべらぼうに高く見えることがあるが、成功した報奨金ハンターが悪用される前にバグを見つけることができれば、その費用対効果は理にかなったものになる。

例えば、レイヤー2ネットワークのポリゴンは最近、悪用を発見したホワイトハットハッカーのGerhard Wagne氏に200万ドルを支払った。これは信じられないような金額に聞こえるが、バグが発見されなかった場合、8億5000万ドルの資金が危険にさらされていたことを考えると、より理にかなっている出典:Polygon Double-Spend Bugfix Review - $2m Bounty。 ImmuneFiのような報奨金プラットフォームを見るだけで、現在提供されている報奨金のヒントがわかる： 例えば、The Graph Protocolのもっとも高いカテゴリの脆弱性には250万ドル、ChainLinkには500万ドルだ。

コミュニティ重視のテストプログラム

私は、テスターは成功する報奨金プログラムの範囲を定義し、どのように実行するかを決定することに関与すべきだと強く感じている。主なことは、チームとして自らプログラムを担当するか、プログラムを立ち上げた組織の人たちと緊密に協力することである。また、誰がチケットのトリアージを行うか、賞金稼ぎがあなたのチームとどのようにやり取りするかについても合意する必要がある。重要でない問題に対して報奨金が提供されることがないように、また、テストチームがバグ報告の責任を保持したい特定の領域を除外できるように、テスターがプログラムの範囲を定義するのを手伝うことが極めて重要だ。エッジケースになりそうな分野や、特定の種類の専門知識が必要な分野については、 バグ報奨金を囲い込む方が理にかなっている。

例えば上記で紹介したCompound（レンディングプロトコル）のバグ報奨金プログラムでは、リスク管理と価格オラクルを扱うプロトコルのComptroller（監査官）実装に行われたパッチを対象としていることが明記されている。これは金融の専門的な知識であり、このようなスキルを持つ人を見つけるために、より多くの人を集めることは理にかなってるのだ。

テスターにとってのバグ報奨金プログラムのさらなる利点

テスターは、オープンソースソフトウェアや組織外のバグ報奨金制度に参加することで、 テストスキルを強化できる。そして小遣い稼ぎもできるかもしれない。

テストチームにとっては、モブテストスキルを練習し、バグを発見するために協力する素晴らしい方法となる。もっとも有名なプラットフォームは HackerOne と BugCrowd である。そこに行って、何か面白そうなものを見つけてほしい。自分のコンフォートゾーンから抜け出して、これまで必ずしもテストしたことのないものをテストするのは、常に素晴らしいアイデアだ。

Web3テクノロジーに特化して取り組みたいのであれば、ImmuneFiにアクセスして、そこで提供されているプログラムをチェックしよう。

ラディカル・オープンネスがいかにテストを改善するか

ラディカル・オープネス（急進的開放性）という興味深い新しいコンセプトが広まっているが、これは間違いなくテストにも当てはまる。これは、2013年に出版された書籍「ラディカル・オープンネス」によって広まった概念である： Anthony D Williams氏とDon Tapscott氏による2013年の著書「Radical Openness: Four Unexpected Principles for Success」によって広まった概念であり、透明性がビジネス環境におけるすべての利害関係者に利益をもたらすと主張している。

ソースをオープンにするようにテストをオープンにするというAndrew Knight氏による最近の優れた投稿では、オープンソーステストの利点が強調されている。

ユーザーとの透明性は信頼を築く。もしユーザーが、物事がテストされ、機能していることを見ることができれば、製品の品質に対する信頼を得ることができる。常に更新されているドキュメントを覗き見ることができれば、製品をより良く使う方法を学ぶことができる。裏を返せば、透明性を確保することで、開発チームは、製品においてもテストにおいても、高い品質を維持する責任を負うことになる。

彼は報奨金プログラムについて話しているわけではないが、原理は同じである。これは群衆の知恵に帰結する。ソフトウェアとその使われ方の精査に関わる人が多ければ多いほど、それが目的に適ったものになる可能性は高くなる。