curlがHackerOneに戻った衝撃の理由：GitHub Security Advisoriesで発覚した「OSSセキュリティ報告」の現実
はじめに
「世界で最も使われているソフトウェアの一つ」──それがcurlだ。
Daniel Stenberg氏が1996年に開発を開始したこのコマンドラインツールは、現在200億〜500億台のデバイスで動作している。iOS、Android、Windows、Linux、ゲーム機、IoTデバイス、さらには宇宙機まで。インターネット通信の基盤として、現代社会の「見えない動脈」とも言える存在だ。
そんなcurlが、2026年1月末に7年間続けたバグバウンティプログラムを終了した。理由は「AI生成の低品質レポート（AI Slop）の急増」だった。
しかし、それからわずか1ヶ月後の2月25日、Daniel Stenberg氏は衝撃の発表を行った。
「GitHubへの移行は間違いだった。HackerOneに戻る」
本記事では、この「ジグザグ移行」の背景にある技術的・組織的課題を紐解き、オープンソースプロジェクトが抱えるセキュリティ報告の難問を浮き彫りにする。
—
5W2H分析
Who（誰が）
Daniel Stenberg氏とcurlセキュリティチーム。Stenberg氏はcurlの創始者であり、現在もプロジェクトのリードメンテナーを務める。彼はオープンソースセキュリティの第一人者であり、curlはCNA（CVE採番機関）としての資格も持っている。
What（何を）
- 2026年1月31日: HackerOneでのバグバウンティプログラムを終了
- 2026年2月1日: GitHub Security Advisoriesに移行
- 2026年3月1日: HackerOneに「バグバウンティなし」で再移行
バグバウンティ（金銭報酬）は廃止したまま、報告プラットフォームだけをHackerOneに戻すという判断だ。
When（いつ）
- 2019年4月: curl初の本格的バグバウンティプログラム開始（HackerOne）
- 2026年1月21日: バグバウンティ終了を発表
- 2026年1月31日: HackerOneでの受付終了
- 2026年2月25日: HackerOneへの復帰を発表
- 2026年3月1日: HackerOneでの受付再開
Where（どこで）
- HackerOne: 脆弱性報告プラットフォーム（SaaS）
- GitHub Security Advisories: GitHubが提供する脆弱性管理機能
- curlプロジェクト: グローバルなオープンソースコミュニティ
Why（なぜ）
#### バグバウンティ終了の理由（1月）
AI生成の低品質な脆弱性レポートが急増し、セキュリティチームのリソースが圧迫されていた。Stenberg氏は「AI Slop」問題に対処するため、金銭的インセンティブを撤廂した。
#### GitHub移行の理由（2月）
多くのオープンソースプロジェクトがGitHub Security Advisoriesを使用しており、curlも「十分に機能するだろう」と考えた。GitHubへの統合により、開発ワークフローとの親和性も高まると期待された。
#### HackerOne復帰の理由（2月下旬）
GitHub Security Advisoriesがオープンソースプロジェクトのニーズを満たしていないことが判明。特に以下の機能が欠如していた：
How（どうやって）
curlセキュリティチームは、以下の要件を満たすプラットフォームを求めていた：
- 報告者はアカウントが必要
- レポートは最初は非公開（報告者とセキュリティチームのみ）
- すべてのレポートは最終的に公開（有効・無効を明記）
- チーム専用の非公開コメント機能
- CVE番号のカスタム入力
- ラベル・タグ機能（AI Slop分類など）
- 虐待ユーザーのブロック機能
- レート制限・アカウント年齢制限など
GitHub Security Advisoriesは、これらの多くを満たしていなかった。
How Much（どの程度）
- バグバウンティ廃止の効果: レポート数は大幅に減少
- HackerOne復帰のリスク: 再びAI Slopが殺到する可能性
- 他の選択肢: GitLab、Codebergなどは「この分野に全く挑戦していない」（Stenberg氏）
—
GitHub Security Advisoriesの「落とし穴」
Stenberg氏はGitHub Security Advisoriesで発見した問題点を詳細にリストアップしている。これは他のオープンソースメンテナーにとっても参考になる重要な情報だ。
1. 秘密情報の漏洩リスク
GitHubはレポート全体をメールで通知する。SMTPは本質的に安全ではなく、エンドツーエンドの保護が保証されない。これにより、未公開の脆弱性情報がメールチェーン全体に漏洩するリスクがある。
2. 無効レポートの公開不可
curlはオープンソースとして「最大限の透明性」を掲げている。無効なレポートも含めてすべて公開したいが、GitHubではこれができない。
3. チーム専用コメントの欠如
虐待的な報告者について議論したり、報告者に見せたくない技術的詳細をチーム内で共有したりする機能がない。
4. CVE番号の編集不可
curlは独自のCNA（CVE採番機関）であり、自前でCVEレコードを発行している。しかし、GitHubのCVEフィールドは編集できず、混乱を招く。
5. ラベル・タグ機能の欠如
IssueやPull Requestにはラベル機能があるのに、Security Advisoriesにはない。これでは「AI Slop」レポートを分類・統計できない。
6. UI/UXの問題点
- セキュリティタブにアドバイザリ数が表示されない
- 個別アドバイザリから一覧に戻るボタンがない
- コメントで@メンションの補完が効かない
- 「引用」機能がない
—
オープンソースセキュリティ報告の「未解決問題」
Stenberg氏は今回の経験から、より大きな問題を指摘している。
> 「他のオープンソースプロジェクトはどうやってこれを使っているのか？オープンソースプロジェクトにとって、バグバウンティなしで適切に安全かつ効率的な脆弱性報告を行える分野は、過小評価されている」
現状の選択肢
| プラットフォーム | 無料 | バグバウンティ | OSS対応 | 評価 |
|—————–|——|—————|———|——|
| HackerOne Community Edition | ✅ | ❌（オプション） | ✅ | curl選択 |
| GitHub Security Advisories | ✅ | ❌ | ⚠️ 機能不足 | 今回不採用 |
| GitLab | ✅ | ❌ | ❌ | 評価外 |
| Codeberg | ✅ | ❌ | ❌ | 評価外 |
| メール | ✅ | ❌ | ⚠️ 管理困難 | 非現実的 |
理想的なソリューション
オープンソースプロジェクトが求めるのは：
- 金銭報酬なしで利用できる
- プロフェッショナルな脆弱性管理機能
- 完全な透明性（無効レポートも公開）
- 柔軟な権限管理
- AI生成レポートへの対抗策
現在、これらをすべて満たすプラットフォームは存在しないかもしれない。
—
AI Slop問題の深層
バグバウンティ終了の直接原因
curlのバグバウンティプログラムは、AI生成の低品質レポートによって圧迫されていた。これらは：
- 明らかに間違い
- 自動生成されたフォーマット
- 実際の脆弱性ではない
- メンテナーの時間を無駄にする
HackerOne復帰のリスク
HackerOneに戻ることで、再びAI Slopが殺到する可能性がある。しかし、Stenberg氏は以下の対策を考えている：
- レート制限
- アカウント年齢制限
- 「AI Slop」タグ付けによる統計
- 虐待ユーザーのブロック
—
開発者が知っておくべき教訓
1. セキュリティ報告プラットフォームの選定は慎重に
「多くのプロジェクトが使っているから」という理由で選んではいけない。自プロジェクトのニーズを明確にし、それを満たすか検証することが重要だ。
2. 透明性とプライバシーのバランス
オープンソースは「透明性」が基本だが、セキュリティ報告では一時的な非公開が必要。このバランスをどう取るか、事前に方針を決めておくべきだ。
3. AI生成レポートへの備え
バグバウンティを提供しないオープンソースプロジェクトでも、AI生成のスパムレポートが来る可能性がある。対策を考えておこう。
4. CNAとしての責任
自プロジェクトがCNA（CVE採番機関）である場合、CVE管理の柔軟性が重要だ。プラットフォームがこれをサポートしているか確認しよう。
—
まとめ
curlの「ジグザグ移行」は、オープンソースセキュリティ報告の難しさを浮き彫りにした。
- GitHub Security Advisoriesは機能不足
- HackerOneは無料で使えるが、AI Slopリスクがある
- 他の選択肢はほぼ存在しない
Stenberg氏の勇気ある「間違いの認識」は、他のオープンソースメンテナーにとって貴重な教訓になるだろう。
もしcurlに脆弱性を発見したら
2026年3月1日以降は、以下から報告すること：
https://hackerone.com/curl
金銭報酬はないが、curlセキュリティチームは真摯に対応してくれるはずだ。
—
コメント