Turso、バグバウンティプログラムを終了
(turso.tech)- Tursoは、データ破損を実証したバグに1,000ドルを支払うバグバウンティを約1年間運用した後、終了した
- 報奨金が設定されると、AI生成の低品質PRが大量に流入し、メンテナーたちは数日間それを閉じる作業に時間を費やした
- 初期には5人に報奨金を支払い、一部の貢献はシミュレーターの改善やSQLiteの10件を超えるバグの発見につながった
- Tursoはvouchingシステムで疑わしいPRを自動的に閉じたが、ボットは手動レビューを求めるIssueや類似PRの再投稿を繰り返した
- Tursoはオープンな貢献を維持するため、システムを閉じるのではなく金銭的インセンティブの撤廃を選んだ
Tursoがバグバウンティを中止した理由
- Tursoは約1年間、データ破損につながりうることを実証したバグに1,000ドルを支払ってきたが、現在このプログラムを終了した
- 金銭的報酬が付いた後、TursoのリポジトリにはAI生成の低品質PRが殺到し、メンテナーは数日間、その大半を閉じることにほとんどの時間を使わざるを得なかった
- Tursoはオープンな貢献を受け入れるプロジェクトであり続けたいが、特定の種類のバグに金銭を支払う仕組みは、オープンな貢献の運営をほぼ不可能にすると見ている
- 今回の決定は、新しい時代のオープンソースガバナンスをどう築くべきかを一緒に学ぶ必要があるという認識のもとで公開された
プログラムを始めた背景
- Tursoは、世界でもっとも信頼性の高いソフトウェアの1つとして知られるSQLiteを再実装しており、それに見合う高い信頼性基準が必要だった
- TursoはSQLite並み、あるいはそれを上回る信頼性を達成するため、複数のテスト体系を運用している
- ネイティブの決定的シミュレーター
- 複数のファザー(fuzzer)
- SQLiteと比較するオラクルベースの差分テストエンジン
- 並行性シミュレーター
- Antithesisでの大規模な実行
- しかしテスト基盤も結局はソフトウェアであり、完全ではなく、ジェネレーターが実際に作り出す組み合わせの範囲でしかバグを見つけられない
- たとえばファザーがインデックスを作成しなければ、システムの他の部分に強いストレスをかけても、インデックス関連のバグは見つけにくい
- Tursoは、データベースが1GBを超えたときにのみ現れるバグを見つけたが、各実行で障害を積極的に注入していたため、データベースがそのサイズまで成長できず、シミュレーターをすり抜けていた
- 関連内容: 互換システム実装の冒険
- 自動テストの利点は、一度すり抜けたバグでも、テストジェネレーターを改善すればそのバグのカテゴリ全体を除去できる点にある
- バグバウンティは、Tursoのテスト手法への自信を示すと同時に、シミュレーターがうまく扱えていない領域を誰かが見つけた場合に報いるための仕組みだった
- 当初の計画では、Turso 1.0のリリース前までデータ破損バグに1,000ドルを支払い、1.0以降は報奨金の規模と対象範囲を段階的に広げていく予定だった
AIによる低品質な投稿が増える前の効果
- プログラム初期には合計5人が報奨金を受け取り、彼らはプロジェクトに有意義な貢献をした
- AlperenはTursoシミュレーターの中核的な貢献者の1人で、改善できる箇所を把握していた
- MikaelはLLMを創造的に使ってシミュレーターが到達できない地点を見つけ出し、その後Tursoに採用された
- Pavan Nambiはシミュレーターと形式手法を組み合わせ、TursoのバグだけでなくSQLite自体でも10件を超えるバグを発見した
AI生成の投稿が生んだ運用負荷
- Tursoが求めていた投稿基準は、単にバグを指摘することではなく、シミュレーターを拡張してデータ破損バグを実証することだった
- この条件のおかげで、報奨金狙いの悪質なPRは少なく、実際のデータ破損バグも多くはなかった
- その後、LLMにTursoを対象にバグを探して報奨金を得るよう指示した投稿が大量に発生した
- LLMはそうした指示を受けると何らかの出力を生成したが、その出力が妥当かどうかは別問題だった
代表的な低品質投稿
-
データベースヘッダーを手動で壊したPR
- PR #6257は、データベースヘッダーにゴミのバイト列を手動で注入したうえで、データベースが破損したと主張した
- メンテナーが当然の結果だと指摘した後も、投稿者またはボットはLLM風の長文反論を続けた
-
ソースコードに直接out-of-boundアクセスを入れた投稿
- 別の投稿では、データベースを破損させるためにソースコードへout-of-bound配列アクセスを手動で追加していた
- 関連Issue: tursodatabase/turso#5508
-
SQL実行を脆弱性だと主張したPR
- PR #4322は、表や緑色のチェックマーク、em dashが並ぶ形式で、任意のSQL文を実行できる致命的な脆弱性を見つけたと主張した
- Tursoは、SQLデータベースがSQL文の実行を許可すること自体を脆弱性とは見なしていない
-
Tursoの同時書き込み機能を誤解したPR
- PR #6874は、Tursoの差別化要素の1つである同時書き込みを有効にしたうえで、ジャーナルモードをWALに戻して同時書き込みを無効にするまでSQLiteがファイルを開けないことを示した
- これはシステムが設計どおりに動作した結果だった
-
意図の把握が難しい投稿
- 別の投稿は、何をしようとしているのか把握しにくい内容だった
- メンテナーのMikaelは、投稿者が報奨金の告知を見てAI生成ツールをTurso向けに使ったものと判断した
最後の対応: vouchingシステム
- Tursoは秩序を取り戻す最後の試みとして、vouching（保証）システムを設計・実装した
- 投稿がボットによるものと疑われる場合に自動で閉じる仕組みで、しばらくの間はある程度機能していた
- その後ボットは、PRが閉じられた理由を問題視して手動レビューを求めるIssueを立て始めた
- PRを閉じると、同じユーザーまたは別のユーザーがすぐに同一または非常によく似たPRを再び開くことも何度も起きた
オープンな貢献と金銭的インセンティブの衝突
- 低品質な投稿を作る側は生成に1分程度しかかけないが、Tursoはそれを読んで理解し、対応するのに何時間も費やさなければならない
- こうした投稿は、事実上ほぼ無限に近い速度で生成できる
- 自動化されたゲートキーピングシステムは作れるが、無視できない金銭的報酬が付くと、AIが議論を続けたり同じPRを再投稿したりするインセンティブが強まる
- Tursoはオープンソースのコントリビューターコミュニティを重視しており、今後も強化していくが、現時点ではオープンなシステムではどのような形の金銭的インセンティブもうまく機能しないと見ている
- 選択肢はシステムを閉じるか、インセンティブをなくすかであり、Tursoは今は後者を選んだ
1件のコメント
Hacker Newsのコメント
ボトルネックはコードを書くことではなく、コードを読んで理解することにある、という話を示している
昔からどのチームにも1人くらい「生産的な」エンジニアがいて、必要かどうかに関係なく、大規模リファクタリングを混ぜた巨大なPRを出していた。ニューラルネットがこんなに大量のコードを生成できるとは想像もしていなかった時代からそうだった
そうした「生産性」の結果は、チームの速度を上げるどころか、ほとんど止めてしまうことのほうが多かった。PRを細かくレビューするのに時間を使い切るか、雑にLGTMして本番で爆発し、全員がまた設計からやり直す羽目になるかだった。しかもその人の「生産性」のせいでプロジェクト構造があまりに速く変わるので、どこに何があるかを明確に把握しているのが、その「とても賢く、才能があり、生産的で、会社の目標に忠実な」1人だけになる
「ほぼすべてのソフトウェア開発組織には、戦術的プログラミングを極限まで押し進める開発者が少なくとも1人はいる。戦術的トルネードだ。戦術的トルネードは、他の人よりはるかに速くコードを量産する多作なプログラマーだが、完全に戦術的なやり方で働く。素早い機能を1つ実装することにかけては、彼より速い者はいない。組織によっては、マネージャーが戦術的トルネードを英雄のように扱う。しかし戦術的トルネードは破壊の跡を残す。後でそのコードに向き合わなければならないエンジニアは、彼を英雄だとは思わないことが多い。たいていは他のエンジニアが戦術的トルネードの残した混乱を片づけることになり、そのせいで本当の英雄であるそのエンジニアたちのほうが、戦術的トルネードより遅く進んでいるように見えてしまう。」
しかもAI生成コードが増えるほど、実際にそのコードを理解している人はさらに少なくなるだろう
それでも回帰テストとリンターがしっかり整っていて、コードが動き、ひどくないと分かっているなら、レビューは文字どおり1文字ずつの正しさを掘り下げるより、全体としての高レベルな品質を見るものになるべきだ。もちろんレビュー自体は相変わらずつらかった
当然ながら、コードを書くより読む・理解する仕事のほうが多く、時には自分が書いたコード行数がマイナスだったこともあり、それを誇らしく思っていた
今ではAIのおかげでさらにコードを書かなくなり、そういう形で達成感を得る夢は諦めた。機械が作ったにせよ人が作ったにせよ、出所の怪しい大量のコードを素早く理解する能力は、特にAIの助けを借りるなら、引退まで価値を持ち続けてほしいと思う。どうだろう？
私たちは機械が実行するためのコードだけでなく、人が読むためのコードも書いている。コードレビュー、デバッグ、将来の変更はすべて、誰かが書いたコードを読んで理解することを含む。そしてその振る舞いに責任を問えるAIが現れるまでは、その理解をAIに委ねることはできない
ボットを誘い込むハニーポット・リポジトリとして、このすばらしいプロジェクトに触れるには良いタイミングだ
https://github.com/UnsafeLabs/Bounty-Hunters
対応するランキングはこちら
https://clankers-leaderboard.pages.dev
AIがこういうリポジトリやその中の活動を学習したら何が起きるのか気になる。Issueのバグ報告は本当に修正可能な問題なのか、それとも作り話のたわごとなのか？
ただ、そう遠くないうちにAIボットのブロックリストに載る可能性が高い
プログラムを閉じるのは完全に合理的だ。ただ、別の選択肢もある。提出者に少額の手数料を払わせて、実際のバグが見つかった場合はそのお金を返すようにすることだ
実際にプログラムが報酬を払っているかどうかは重要ではない。レポートが1件でも誤ってクローズされれば、その話は延々と蒸し返される
そういう場合、今でも時間を失うのに、今後は金まで失うことになる
特に小さな会社なら、提出前にその会社がどう反応するか分からない
提出前にシミュレータのテストスイート全体の実行を必須にすることもできるのではないか？ 提出者がシミュレータを壊していないか確認する良いチェックになるし、副次的に作業証明の成果物も作れるかもしれない。可能かどうかは、セキュリティ方面に詳しくないので分からない
1年以上、TursoDBに単一ファイルを読み込ませようとしているが、まだ成功していない: https://github.com/ClickHouse/ClickBench/issues/336
Hacktoberfestが今でも全員にTシャツを配っていたら、今どうなっていただろうと思う。おそらく世界中で綿花が足りなくなっていただろう
これを防ぐ責任を個々のメンテナーに負わせるべきではなく、GitHubやGitLabが、こういうアカウントがPRを開ける段階に行く前に止めるべきだと思う。本質的にはスパムだ
記事で最初に言及されているPRを作ったユーザーを見てほしい: https://github.com/Samuelsills. こういうアカウントは有名リポジトリにPRを開ける場所の近くにすら行くべきではない
詳しくない分野なので愚かな質問かもしれないが、提出されたシミュレータ変更が既存機能を壊していないことを確認するため、最後にシミュレータの全テスト実行を要求したら、それは作業証明の役割を果たせるだろうか？
バウンティプログラムの代わりに、一種の真偽予測市場を作ったらどうだろう
公開の場で答えに賭けてもらい、各自が自分のトークンを使ってレポートの実体を検証したうえで賭けを買う方式だ。多数が偽だと判断すれば運営が勝ち、多数が本物だと判断すれば運営が支払う
冗談だが、もしかするとそうでもないかもしれない
Tursoを本番環境で使ったことがある人はいる？ Rustで書き直されたSQLite互換実装で、複数ライター対応のような機能が追加されていて、SQLiteと違って外部コントリビューションにも開かれている
フルスタックRustアプリで使ってみようかと思っている。何もかもcargoで動くし、SQLiteを別途持ってこなくていいからだ
TursoはDBaaSもかなり太っ腹な無料プランで提供していて、それが自分が使ってみた主な理由だった
https://x.com/doodlestein/status/2052910351474209258
同じやり方で対抗して、独自のAIボットを配備してPRを事前審査させることはできないのか？
「これを防ぐための自動化システムを設定することはできるが、無視しがたい金銭的価値が付いていると、AIたちが議論を続け、同じPRを再び開かせるよう仕向けるインセンティブが強すぎる」
部外者の視点からすると興味深い難題だ。あのボットからのリクエストのうち、どれだけ多くのエージェントが自分たちのバックエンドでTursoを使っているのだろう？