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

千の失敗による死

2025年7月14日原文(daniel.haxx.se)

概要

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ドル払って報告するのは全然気にしないよ。

Hacker Newsで議論の続きを見る