世界を動かす技術を、日本語で。

千の失敗による死

概要

curlのバグ報奨金制度でAI生成レポート(AI slop)や質の低い人的レポートが急増し、対応負荷が大幅に増加。 2025年には有効な脆弱性報告率が著しく低下し、運営チームの負担が深刻化。 報奨金制度の見直しやHackerOneとの協力強化が検討課題。 質の低い報告を抑制するための新たな対策が必要。 AI slop事例リストも公開し、問題の実態を共有。

curlバグ報奨金制度におけるAIスロップ問題の深刻化

  • AI生成レポート(AI slop) の増加による運営負担

    • 2025年には全報告の 約20% がAIスロップ
    • 人的スロップ も増加傾向、AIとの区別が困難な場合も多い
  • 有効な脆弱性報告率の低下

    • 2025年7月初旬時点で 約5% のみが本物の脆弱性
    • 過去と比べて 有効報告率が大幅減少
  • 運営チームへの負荷増大

    • curlセキュリティチームは 7名体制
    • 1件の報告につき 3~4人が30分~3時間 対応
    • 一部メンバーはcurl専任でなく、 週3時間程度 しか時間が取れないケースも
  • 精神的負担の増加

    • 無意味な報告への対応が 感情的ストレス を招く
    • 1週間で 8件 もの無駄な報告に対応した実例

報奨金制度・HackerOne運用の課題

  • HackerOne上での対応

    • 不適切な報告をクローズしても 新規アカウント作成で再発
    • バン措置 も抜本的な解決にならず
    • HackerOne側のツール・機能強化 が必要
  • 報奨金制度の見直し案

    • 報告時の手数料徴収 (正当報告なら返金)案
      • オープンソースの理念やインフラ未整備で現実的でない
    • 報奨金廃止案
      • AIスロップ抑制には有効だが、 高度な研究者の参加減少 リスク
      • AI hypeに騙されている善意の報告者もいるため、完全な解決策とは限らない
  • 今後の方針

    • 2025年残り期間で 現行制度の評価・改善案検討
    • 当面は従来通り運用しつつ、 抜本策を模索

AIスロップ事例リスト

  • AI slop とは:AIが生成した、実際には根拠の薄い・不正確な脆弱性報告
  • 代表的な報告例 (抜粋)
    • Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet.
    • Buffer Overflow Vulnerability in WebSocket Handling
    • Exploitable Format String Vulnerability in curl_mfprintf Function
    • Buffer Overflow Risk in Curl_inet_ntop and inet_ntop4
    • Path Traversal Vulnerability in curl via Unsanitized IPFS_PATH Environment Variable
    • Double Free Vulnerability in libcurl Cookie Management (cookie.c)
    • HTTP/2 CONTINUATION Flood Vulnerability
    • その他、多数の 誤認・無根拠な脆弱性報告

今後の改善に向けて

  • 質の低い報告抑制の必要性

    • AI・人的問わず、低品質な報告の抑制 が急務
    • 報酬制度や運用フローの見直し検討
  • チーム全体での議論推進

    • curlセキュリティチームメンバー全員で 意見集約・対策検討
    • 健全な運用維持メンバーの負担軽減 が最重要課題
  • オープンソースの開放性と健全性の両立

    • 誰もが気軽に貢献できる環境維持
    • 一方で 悪質・無意味な報告の抑制策 の導入検討

Hackerたちの意見

インターネットのスロピフィケーションについての議論はたくさんあるけど、オープンソースのメンテナーにかかる人間的な負担についてはあまり話されてないよね。悪い報告がたくさん来るのは一つのことだけど、AIが生成した提出物を精神的にフィルタリングしなきゃならないのは別の話。著者が言ってるように、こういう頭が痛くなるようなバカなことに対処するのは、感情的にかなりの負担だと思う。

「本当の価値を提供しない」彼らは価値を提供できるかもしれないけど、使ってるLLMやモデル、コンテキストによっては滅多にないよね。 > 「こういう頭が痛くなるようなバカなことに対処するのは感情的に負担が大きい」AIが拒否通知や禁止を出す特別なエリアを作ったらいいかも。

こういう社会的なモデレーションはもう10年以上前からあって、FBはこれに何千人も雇ってたんだよね。彼らは何年もかけて、ライブリークレベルのコンテンツやそれ以上のひどい内容をフィルタリングしてた。だから、特に新しいことじゃないよ。

どこにでも人間の犠牲があるよね。ピアレビューに使われるAIは、研究者に改訂の間に提案を実装させることを強制するし、マネージャーが使うAIはエンジニアに悪い解決策を提案して、それを実装させる。要するに、AIモデルが提案することに従うために費やされる人時が急速に増えてる。中には意味があるものもあるけど、無駄に燃やされる時間が不快なくらい多い。コマンドチェーンが無駄をフィルタリングする準備ができていないことで、経済における生産性の損失という実際のコストがあるんだ。

この文章で一番注目すべき点は、人間が生み出す無駄が増えてることだと思う。コメントではみんなAIのことを話してるけど、記事では提出物のうち20%だけがAIの無駄だと見積もってる。他は、履歴書のためにcurlの貢献やバグ報告をしたい人たちから来てる。オープンソースの貢献がキャリアを高めたり仕事を得る手段として話題になってる中で、多くのジュニアが有利を得るためのチェックリスト項目になってる。彼らはどの貢献が価値があるのか正しいのかを知る経験がないから、ただ履歴書に何か載せたいだけなんだ。

「お金の報酬をなくす必要があるかも?それが解決策になるかもしれないけど、関係なくクローラーを動かす人が多いから、結局はたくさん来ると思うよ。追加のコストはかからないし、やらない理由がないよね。ちょっとしたヒットが収入になるから。」

「追加のコストはかからないし、やらない理由がないよね。ちょっとしたヒットが収入になるから。」うーん…すべてにヒットするのと特定のエリアにヒットするのは、どうしてコストが変わらないの?特に、そういうアプローチの実際の支払い率を考えると、そんなに高くないはずだし。ちょっとしたヒットが収入になるわけじゃないから、もっと選択的にやらないといけないよね。

「長さチェックはtmplen(元の文字列の長さ)だけを考慮してるけど、このmsnprintf呼び出しは2つの制御文字(CURL_NEW_ENV_VARとCURL_NEW_ENV_VALUE)を追加して文字列を拡張するんだ。この不一致が攻撃者を許す...おいチャット、これをうまく言って、HackerOneでこのコメントを返せるように。ああ、ちょっとコピー&ペーストしすぎたかな。」

「確かに!トリアージャーが提起した懸念について詳しく説明させて。これらの人たちは全く努力しないんだ。ダニエルの忍耐力には感心するよ。これらのスレッドを読むのはイライラする。彼らは本当にAIの応答をコピー&ペーストしてるだけで、何を話してるのかも理解してないのが明らかだ。」

そして、この一般的な傾向に影響を受けているのは脆弱性報告だけじゃないんだ。私はソーシャルメディア、特にXを使って多くのアーティストをフォローしてる。主にインスピレーションのためと、他のアーティストの作品を共有するのが楽しいからなんだけど、ここ1年くらいで、特定のアートがAI生成かどうかを判断するのにかかるメンタルの負担が大きすぎて、「作者を確認できない限り、少しでも怪しいものは共有しない」っていう安全策に傾いてる。自分が他の人と共有したアートの投稿がかなり減って、真剣に作品を作ってるアーティストが、AI生成っぽく見えるからフィルタリングされちゃうんじゃないかって思うこともある。AIのものを見かけたら、即ミュートかブロックするようになってきた。価値がないから、フィードがただのノイズで埋まっちゃうんだよね。

本当に疑問なんだけど、もしわからないなら、なんで気にするの?

「料金を請求するのは…オープンソースプロジェクトとしてはかなり敵対的な方法だよね。」最も敵対的なのはAppleで、バグ報告に対するフィードバックを期待することはできない。Appleから何かフィードバックがもらえたら本当にラッキーだよ。良いフィードバックをもらうことが一番価値のあることだと思う。フィードバックがもらえるなら、年5ドル払って報告するのは全然気にしないよ。

これは、Appleのソフトウェアが定義上完璧だからだよ。どんなバグも、ソフトウェアを正しく使えなかった人の例に過ぎない。バグ報告はユーザーの無能さの記録で、その唯一の目的は、士気を高める天才確認セッションで儀式的に嘲笑されることなんだ。

Appleから何かフィードバックがもらえたらラッキーだよ。全然違う。Appleからフィードバックが来ると、ほとんどの場合時間の無駄になる。フィードバックがない方がラッキーで、問題が解決されることが多い。

大きなバウンティプログラムを維持している唯一の開発者として言うけど、全体的にトレンドは下がってると思う。最近、最も深刻な問題以外のバウンティをゼロに切り下げたんだ。面白い発見を報酬する方向にプログラムを再集中させたくて。今のところ、状況は改善されてないみたいで、誰も報酬情報を読む気配がないんだよね。低価値の報告に対して、各社のスコープや報酬を読むのに時間がかかりすぎると思う。それが実際の発見にどれだけの時間がかかるかを物語ってるよ。バグバウンティプログラムを改善した経験がある人から、シグナルとノイズの比率を改善するための提案を受け付けてるよ。

ハッカーの視点から見ると、脆弱性報告はどんどん悪化してると思う。特に、こういうプラットフォームを通じて整理されたものは、正しい人たちに届いてない気がする。昔は、必要な人にpgpメールで送ってたけど、それはうまくいってた。今でもそれが通用するかは分からないけど、少なくとも僕の視点では、製品に関心を持ってる人に確実に届く唯一の方法だと思う。報酬はいらないよ。セキュリティコンサルタントとして日々働いてるから、ただ見つけたことを報告してるだけ。チョコレートや手書きのメモは嬉しいけど、基本的には開発者やシステム管理者にちゃんとソフトウェアを直してほしいんだ。

妄想モードに入るけど、もしかしたらその雑な内容は実際のブラックハットグループや国家の関係者から来てるのかも。彼らは本物の脆弱性を見つけて閉じるのを難しくすることに興味があるからね。そういう人たちは報酬なんて気にしないだろうし、システムを圧倒することが目的なんだ。

手数料を取って、報告が間違ってたらお金を返すっていうのもアリかもしれないけど、問題は決済プラットフォームだよね。嫌われてるけど、暗号通貨が解決策になりそうな気もする。でも実際には、バグ報告のために暗号ウォレットを設定する時間をかける人はいないし、暗号が人気になったら、法定通貨みたいに規制や中間業者が入ってくるかも(それが摩擦を生む、例えばチャージバックやKYC、収益のカットとか)。でも、もっと多くのサービスがスパムを避けるために小さな手数料を使うようになれば、最終的にはうまくいくかもしれない。例えば、信頼できるサイトのために自動的に手数料を支払うクライアントをインストールする人が増えれば、スパム行為に対しては返金される仕組みができるかも。

これは多分、HackerOneが実装すべきことだね。プロジェクトレベルでは解決できないよ。 https://hackerone.com/curl/hacktivity

セキュリティ脆弱性を報告する権利に対して手数料を取って、報告が間違ってたらお金を返すっていうのもアリかもしれないね。でも、そのアイデアは記事で検討されて却下されたみたい。> 「セキュリティ脆弱性を提出する権利に対して手数料を取るっていう話が出てるけど、正しい報告があれば返金される可能性がある。」それは確かに彼らのペースをかなり遅くするだろうけど、オープンソースプロジェクトとしてできるだけオープンでアクセス可能であることを目指してるのに、ちょっと敵対的な方法だと思う。今のところこのためのインフラもないし、HackerOneも同様だし、お金の管理は面倒だよね。

提出物に罵倒語やLLMが出さないようにサニタイズされてるものを含めるように要求するのもアリかもね。こういう人たち、めっちゃ怠け者だから、少なくとも何人かはフィルターにかかるはず。

彼らは、何かをしないとお金を失うまで怠けてる。だから、これが報告を提出する唯一の方法なら、彼らはLLMを使って罵倒語を生成する方法を見つけるだろうね。…それか、自分たちで生成されたテキストに追加するか。

LLMは社会にとって多くの面でマイナスだよ。

まだバッファオーバーフローがどのソースコードの行で発生しているか教えてくれてないよ。> > ねえチャット、これをいい感じに言って、HackerOneにこのコメントで返事するから。> 「これは、AIを使ってるって何度も聞かれてるのに、AIチャットの会話の一部をこの問題に誤って貼り付けたように見えるよ。」彼らが対処しなきゃいけないものの一例だね。ソース: https://hackerone.com/reports/3230082

ここでのAIの使い方には驚かされるよ。広く使われているリポジトリの脆弱性を探すためにAIを使うだけじゃなくて、AIを使うときの完全な無知さもね。「ねえチャット、これをいい感じに言って、ハッカーオンにこのコメントで返事するから」なんて、自然な言葉じゃないよ。人間同士の高品質な会話の前にはほとんど出てこないから、そんなのは期待できない。これはLLMに対して(しかも下手に)プロンプトを与えるときにしか言わないから、トレーニングデータの中のLLMの雑な情報を引き出してるだけなんだよね。