curlがHackerOneに戻った理由：OSSセキュリティ報告の現実とAI Slop問題【2026年版】

60秒でわかる結論

curl（カール）という世界で最も使われているソフトウェアの一つが、2026年に「バグバウンティプログラムを終了→GitHub Security Advisoriesに移行→HackerOneに戻る」というジグザグの判断を下しました。背景には、AI生成の低品質レポート（AI Slop）の急増と、GitHub Security Advisoriesがオープンソースプロジェクトのニーズを満たしていなかったという現実があります。この記事では、Daniel Stenberg氏（curl創始者）が公表した詳細な検証結果をもとに、オープンソースセキュリティ報告の現在地と課題を解説します。

curlとは何か：なぜこの話が重要なのか

curlはDaniel Stenberg氏が1996年に開発を開始したコマンドラインツールで、現在200億〜500億台のデバイスで動作しています。iOS、Android、Windows、Linux、ゲーム機、IoTデバイス、さらには宇宙機まで。インターネット通信の基盤として、現代社会の「見えない動脈」とも言える存在です。

そんな社会的インフラとも言えるソフトウェアが、セキュリティ報告の受け皿をどう設計するか──これは単なるcurlの問題ではなく、すべてのオープンソースプロジェクトが直面する普遍的な課題です。事実、Go言語のセキュリティリードであるFilippo Valsorda氏も、AI時代における脆弱性報告の前提が変わったことを指摘しています。

curlの対応は、Googleの脅威防御技術やAI×サイバーセキュリティ完全ガイド2026で解説している自律型セキュリティとは異なる、コミュニティ主導の透明性重視アプローチというもう一つの道を示しています。

タイムライン：ジグザグ移行の全貌

curlのセキュリティ報告プラットフォームは、以下のように激しく移行しました。

GitHub Security Advisoriesの「落とし穴」6つ

Stenberg氏はGitHub Security Advisoriesを使ってみて、以下の問題を発見しました。これらは「GitHubの機能が悪い」ではなく、オープンソースプロジェクト特有のニーズと乖離していたという点が重要です。

1. 秘密情報の漏洩リスク

GitHubはレポート全体をメールで通知します。SMTPは本質的に安全ではなく、エンドツーエンドの保護が保証されません。これにより、未公開の脆弱性情報がメールチェーン全体に漏洩するリスクがあります。curlはCNA（CVE採番機関）でもあるため、CVEレコードの取り扱いには特に慎重さが求められます。

2. 無効レポートの公開不可

curlはオープンソースとして「最大限の透明性」を掲げています。無効なレポートも含めてすべて公開したいが、GitHubではこれができません。これは curl が長年大切にしてきた「オープンな記録」の文化と衝突しました。

3. チーム専用コメントの欠如

虐待的な報告者について議論したり、報告者に見せたくない技術的詳細をチーム内で共有したりする機能がありません。セキュリティチームの心理的安全性が損なわれる問題です。

4. CVE番号の編集不可

curlは独自のCNA（CVE採番機関）であり、自前でCVEレコードを発行しています。しかし、GitHubのCVEフィールドは編集できず、混乱を招きました。これは curl がコミュニティに貢献してきた「CVE発行権限」という権威を、ツール上で活かせない状態を意味します。

5. ラベル・タグ機能の欠如

IssueやPull Requestにはラベル機能があるのに、Security Advisoriesにはありません。これでは「AI Slop」レポートを分類・統計できません。量が問題になる時代において、分類・統計機能の欠如は致命的です。

6. UI/UXの問題点

セキュリティタブにアドバイザリ数が表示されない、個別アドバイザリから一覧に戻るボタンがない、コメントで@メンションの補完が効かない、「引用」機能がない──これらは日常的な運用負荷を増やす要因です。

プラットフォーム比較：どこを選ぶべきか

Stenberg氏が検証した結果、以下のような比較になりました。

Stenberg氏の言葉が象徴的です。「他のオープンソースプロジェクトはどうやってこれを使っているのか？オープンソースプロジェクトにとって、バグバウンティなしで適切に安全かつ効率的な脆弱性報告を行える分野は、過小評価されている」

AI Slop問題の深層

このジグザグ移行の根本原因はAI Slopです。curlのバグバウンティプログラムは、AI生成の低品質レポートによって圧迫されていました。これらは明らかに間違い、自動生成されたフォーマット、実際の脆弱性ではない、メンテナーの時間を無駄にする──という特徴を持ちます。

実は、この問題は curl だけのものではありません。AIが生成した低品質なコードやドキュメントがOSSエコシステムに与える影響については、RFC-406iでOSS標準として定義する動きもあります。Flask生みの親であるArmin Ronacher氏も、AIがAIを動かす時代の到来を「The Coming Loop」として警告しています。この問題は、ISO/IECやEU AI Act、NIST RMFなどのAIガバナンス枠組みの観点からも重要です。

開発者が知っておくべき3つの教訓

これらの教訓は、偽の求人面接バックドアで解説した開発者を標的とした攻撃への対策とも共通します。セキュリティ報告の仕組みを理解しておくことは、単なる運用の話ではなく、開発者自身の防衛力にも直結します。

🔍 筆者の分析：5つの視点

1. インフラとしてのOSSと報告インフラの非対称

curlは200億〜500億台のデバイスで動くインフラ級ソフトウェアです。しかし、そのセキュリティ報告を受け止めるプラットフォームは、現状どれも「十分ではない」。これはソフトウェアの重要性と、それを支える報告インフラの成熟度の間に巨大なギャップがあることを示しています。社会的インフラに近いソフトウェアを、ボランティアベースのコミュニティが支え、しかもその報告の受け皿すらない──この構造的欠陥は早晩どこかで破綻する可能性があります。

2. 「主流＝正解」という幻想の崩壊

curlがGitHub Security Advisoriesを選んだ理由は「多くのオープンソースプロジェクトが使っているから」でした。しかし実際に使ってみると、curlが求める透明性・CNA権限・チーム専用コメントなどのニーズが満たされていませんでした。これは「みんなが使っているから安全」という前提が、OSSの世界では必ずしも成り立たないことを示す象徴的な事例です。自プロジェクトの要件を明確化し、検証する文化が必要です。

3. AI Slopという新時代の構造的課題

AI生成レポートがバグバウンティを壊したという事実は、AIがコードを書く時代の新しい摩擦を示しています。AIコーディングツールが普及する中で、AIが生成する「もっともらしい脆弱性報告」は今後も増え続けます。これに対抗するには、レート制限・アカウント年齢制限・AI Slopタグ付け・虐待ユーザーブロックなどの組み合わせが必要です。金銭的インセンティブの撤廃は一時的な対応であり、根本解決にはAI生成物の品質をどう判定するかという技術的・社会的な仕組みが必要です。

4. 日本のOSSコミュニティへの示唆

日本のOSSプロジェクトも、同じ課題に直面します。特に日本語圏からの報告は、言語の壁もありAI生成レポートと本物の報告の判別がさらに困難です。curlの事例から学べるのは、報告プラットフォームの選定は「機能の有無」ではなく「自コミュニティの運用フローに合うか」で判断すべきという点です。また、CNA（CVE採番機関）としての地位を持つプロジェクトは、CVE管理機能の柔軟性を事前に確認すべきです。

5. 透明性という「OSの良心」

curlが「無効なレポートも含めてすべて公開したい」と考えるのは、オープンソースの根幹にある透明性への信念からです。これは単なる好みではなく、コミュニティの信頼を維持するための構造的な仕組みです。GitHub Security Advisoriesがこれを満たさなかったことは、プラットフォーム提供者がOSSの文化をどれだけ理解しているかという問いでもあります。今後、HackerOneがこのニーズをどこまで満たせるかが、OSSセキュリティ報告の将来を左右します。

日本のOSSエコシステムへの影響

curlの事例は、日本のオープンソースエコシステムにも重要な示唆を与えます。日本発のOSSプロジェクトは増えていますが、セキュリティ報告の受け皿設計については、欧米の先行事例を追試する段階にとどまっています。特に以下の3点が日本固有の課題として浮上します。

1. 言語の壁とAI Slop判定の難しさ

日本語で書かれた脆弱性報告の場合、AI生成か人間執筆かの判定が英語圏よりも困難です。機械翻訳特有の不自然な表現と、AIが生成する「もっともらしい日本語」の区別は、母語話者でも迷うレベルになりつつあります。日本のOSSメンテナーは、この判定負荷を前提とした運用設計が必要です。

2. CNA（CVE採番機関）の少なさ

日本企業でCNA資格を持つ組織は限られています。curlの事例が示すように、CVE発行権限を持つプロジェクトは、ツール上でその権限を活かせるか確認が必要です。日本のOSSプロジェクトが将来的にCNAを目指す場合、報告プラットフォームの選定は戦略的な判断になります。

3. コミュニティの持続可能性

curlはDaniel Stenberg氏を中心に、ボランティアベースで20年以上維持されています。日本のOSSプロジェクトも、個人に依存しすぎる持続可能性の問題を抱えています。セキュリティ報告の仕組みを、個人ではなくコミュニティ全体で支える構造をつくることが、長期的な健全性の鍵です。

まとめ：3つのポイント

1. curlのジグザグ移行は、AI Slop問題とGitHub Security Advisoriesの機能不足が重なった結果。HackerOne復帰は「主流」の選択が必ずしも正解でないことを示す事例。
2. GitHub Security Advisoriesの6つの問題（秘密情報漏洩リスク・透明性欠如・チーム専用コメント不可・CVE編集不可・ラベル機能なし・UI/UX問題）は、OSSプロジェクトが自ニーズを明確化する重要性を浮き彫りにした。
3. AI Slop問題は構造的課題であり、金銭報酬の撤廃は一時対応。AI生成物の品質判定と、報告プラットフォームの機能改善が今後の鍵。

FAQ：よくある質問

Q1. curlとは何ですか？

curl（カール）は1996年にDaniel Stenberg氏が開発したコマンドラインツールで、URLを使ってデータを転送するためのソフトウェアです。現在200億〜500億台のデバイスで動作しており、インターネット通信の基盤となっています。

Q2. なぜcurlはバグバウンティを終了したのですか？

AI生成の低品質な脆弱性レポート（AI Slop）が急増し、セキュリティチームのリソースが圧迫されたためです。金銭的インセンティブがあると、報酬目当てのAI生成レポートがさらに増えるという判断でした。

Q3. GitHub Security Advisoriesはダメなプラットフォームですか？

「ダメ」ではなく、curlが求めるニーズと合わなかったというのが正確な表現です。多くのプロジェクトで使われていますが、OSSプロジェクト特有の要件（完全な透明性・CNA権限・チーム専用コメントなど）を満たしていませんでした。

Q4. HackerOneに戻った理由は何ですか？

HackerOne Community Editionが、curlが求める機能（透明性・チーム専用コメント・CVE編集・ラベル機能・虐待ユーザーブロックなど）を最も多く満たしていたためです。バグバウンティ（金銭報酬）はなしのまま、報告プラットフォームとして復帰しました。

Q5. AI Slopとは何ですか？

AI生成の低品質レポートの総称です。明らかに間違い、自動生成されたフォーマット、実際の脆弱性ではない、メンテナーの時間を無駄にする、という特徴を持ちます。詳細はRFC-406iで解説しています。

Q6. 日本のOSSプロジェクトはどう備えるべきですか？

報告プラットフォーム選定時に、自プロジェクトのニーズ（透明性の方針・CVE発行権限・チーム内部の議論方法・AI生成レポート対策など）を明確化し、候補プラットフォームがそれを満たすか検証することが重要です。

Q7. この話題は自分にどう関係しますか？

curlを含むOSSソフトウェアは、あなたのスマートフォン、PC、クラウドサービスの裏側で動いています。そのセキュリティ報告の仕組みが健全に保たれることは、デジタル社会全体の安定性に直結します。また、開発者であれば、自分のプロジェクトでも同じ課題に直面する可能性があります。

公式・関連情報源

• curl公式サイト — curlプロジェクトの公式サイト（Daniel Stenberg氏運営）
• curlセキュリティ情報（公式） — curlの脆弱性報告・CVE情報
• HackerOne公式サイト — 脆弱性報告プラットフォーム（curlが現在利用中のCommunity Edition含む）
• Python Requests（GitHub） — 代表的なOSSプロジェクトのセキュリティ報告事例
• CVE公式サイト — 共通脆弱性識別子（CVE）の管理機関
• Wikipedia: curl — curlの歴史と技術の百科事典記事
• Wikipedia: HackerOne — HackerOne社の百科事典記事