実態と乖離した脆弱性報告に関する調査レポート

# 実態と乖離した脆弱性報告に関する調査レポート ## 更新履歴 | 日付 | 更新内容 | | ---------- | ------------------------------ | | 2026-02-08 | 初版作成 | | 2026-03-08 | 利害関係の開示と、本記事の作成プロセスを追記 | ## 1. 背景と目的近年、オープンソースソフトウェア（OSS）プロジェクトに対して、実態と乖離した脆弱性報告が確認されている。本調査は、それら脆弱性報告を調査し、その原因、影響、および対策を検討することを目的とする。調査の契機となった主な事例は以下のとおり。 - curl: AI生成の低品質レポート（AI slop）の洪水によりバグバウンティプログラムを終了 - node-ip: 誇張されたCVE評価により開発者がリポジトリをアーカイブ - FFmpeg: GoogleのAIが発見した低品質なバグ報告に対し「ボランティアに仕事を押し付けている」と批判 - zlib: ライブラリ本体ではなくリファレンスコードの脆弱性が、あたかも本体の脆弱性として報告なお、本調査は2026年2月8日時点の公開情報に基づいており、各事例のステータス（CVEの状態、プロジェクトの方針等）はその後変化している可能性がある。また、第7章の考察は調査結果に基づく筆者独自の視点であり、第2章〜第6章の事実調査とは性質が異なる点に留意されたい。本調査レポートにおける発言や事例の引用は、特定の団体または個人を批判することを目的としたものではなく、脆弱性報告を取り巻くエコシステムの構造的課題を明らかにするためのものである。 > **【筆者注記】利害関係の開示** > 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。 > 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。 > **本記事の作成プロセス** > 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。 ## 2. 問題の類型調査の結果、虚偽・誇張された脆弱性報告は、主に以下の4つの類型に分類できる。 ### 2.1 AI生成の低品質レポート（AI Slop）「AI slop」とは、AI/LLMを使用して生成された、低品質かつ検証不十分な脆弱性報告を指す造語である[^1]。 #### curl プロジェクトの事例 curlプロジェクトの創設者Daniel Stenbergは、2026年1月21日、AI生成レポートの洪水によりバグバウンティプログラムの終了を発表した[^2]。主な経緯は以下のとおり。 - 2026年最初の21日間で20件のAI生成バグレポートを受領 - 7件が1週間で到着したが、いずれも実際の脆弱性を特定していなかった - 6年間のAI支援レポートで、AIのみで発見された真の脆弱性は**ゼロ** - プログラムは2019年の開始以来、プログラム終了時点までに$100,000以上を支払ってきた Stenbergは以下のように述べている[^3]。 > We have concluded the hard way that a bug bounty gives people too strong incentives to find and make up 'problems' in bad faith. > （参考訳：バグバウンティは、悪意を持って問題を見つけたり作り上げたりする動機を人々に与えすぎることを、私たちは苦い経験から学びました。） #### Python Software Foundation の事例 Python Software Foundationのセキュリティ開発者Seth Larsonは、2024年12月のブログで「slop security reports」の問題を指摘した[^4]。 > Recently I've noticed an uptick in extremely low-quality, spammy, and LLM-hallucinated security reports to open source projects. The issue is in the age of LLMs, these reports appear at first-glance to be potentially legitimate and thus require time to refute. > （参考訳：最近、オープンソースプロジェクトに対する非常に低品質でスパム的、LLMが幻覚したセキュリティレポートの増加に気づいています。LLM時代の問題は、これらのレポートが一見正当に見えるため、反論するのに時間がかかることです。） Larsonが所属するCPython、pip、urllib3、Requestsなどのトリアージチームは、定期的にAI生成レポートの負担を受けている。 #### Django の対応 Djangoは2025年、security.txtにAI生成レポートへの対策を追加した[^5]。報告者に対し、AI使用の開示、報告内容の検証、捏造コンテンツの排除を義務付けている。 > Never thought I'd be writing official docs for a major open source project begging LLMs to stop fabricating surreal vulnerabilities. > （参考訳：主要なオープンソースプロジェクトの公式ドキュメントで、LLMに超現実的な脆弱性の捏造をやめるようお願いすることになるとは思いませんでした。） > — Natalia Bidart, Django Fellow #### FFmpeg の事例 FFmpegは、GoogleのAI脆弱性検出ツール「Big Sleep」によるバグ報告を「CVE slop」と批判し、パッチの提供なしにボランティア開発者へ修正負担を押し付けていると公に抗議した[^6]。報告の象徴的な例が、1995年のゲーム「Rebel Assault 2」のLucasArts Smushコーデックの最初の10-20フレームに関するバグであった。FFmpegはあらゆる動画ファイルの再生を目指すプロジェクトであり、このような古いコーデックもサポート対象だが、その修正を外部から一方的に求められる構図が問題視された。 #### libxml2 メンテナーの辞任 libxml2（XMLパーサライブラリ）のメンテナーNick Wellnhoferは、2025年9月15日にメンテナーの辞任を発表した[^7]。Wellnhoferはこれに先立つ2025年5月、セキュリティエンバーゴ（脆弱性情報の非公開取り扱い）の終了を宣言しており、その際に「第三者から報告されるセキュリティ問題の対応に毎週数時間を費やしている。これらの問題のほとんどは重大ではないが、それでも多くの作業が必要」と述べていた。辞任発表後も2025年末まではリグレッション修正を継続するとしたが、2025年12月をもってプロジェクトは事実上メンテナンス不在となった。 ### 2.2 誇張されたCVSS スコア #### node-ip の事例 Node.js用IPアドレス管理パッケージ「node-ip」（週1,700万ダウンロード）は、2024年2月にCVE-2023-42282として脆弱性が報告された[^8]。経緯は以下のとおり。 1. 16進数形式のIPアドレスが正しく識別されない問題が報告 2. NVDでCVSS **9.8（Critical）** が付与 3. 開発者Fedor Indutnyは重大性を否定 4. 修正後も「npm audit」が警告を出し続け、ユーザーからの問い合わせが殺到 5. 2024年6月26日、Indutnyはリポジトリを**アーカイブ（読み取り専用化）** 6. GitHubが深刻度を引き下げた後、1週間後に復元 Indutnyは以下のようにコメントした[^9]。 > Someone filed a dubious CVE about my npm package, and then I started getting messages from all people getting warnings from 'npm audit'. > （参考訳：誰かが私のnpmパッケージについて疑わしいCVEを提出し、その後「npm audit」の警告を受けたすべての人からメッセージが届き始めました。） #### curl CVE-2020-19909 の事例 2023年8月、curlに対しCVE-2020-19909（CVSS **9.8**）が登録された[^10]。問題点は以下のとおり。 - 2019年7月に報告され、2019年9月に修正済みのバグ - --retry-delayオプションの整数オーバーフロー - 開発者は「リモート悪用やコード実行にはつながらない」と主張 - 最終的にCVSS **3.3（Low）** に修正 Stenbergは以下のように批判した[^11]。 > NVDが実際に脆弱性を理解したり把握したりすることにそれほど熱心に取り組んでないことは前からわかっていました。『整数オーバーフロー』という単語だけを見て、『ああ、なんと恐ろしい欠陥なんだ』と理解したみたいですが、明らかにNVDのスタッフは誰も自分の頭を働かせず、脆弱なコードやバグを修正するパッチをチェックしていませんでした。 #### micromatch の事例週約9,000万ダウンロード（2026年2月時点）のnpmパッケージ「micromatch」に対し、CVE-2024-4067としてReDoS脆弱性が報告された[^12]。メンテナーJon Schlinkertは以下のようにコメントした。 > I get these issues all the time for things that can't even be a vulnerability unless you do it to yourself. > （参考訳：自分でやらない限り脆弱性にすらならないものについて、こういう問題を常に受け取っています。）他のコメンターは、このような報告がCVE全体の品質を低下させ、「狼少年」シナリオを引き起こしていると指摘した[^13]。 ### 2.3 ライブラリ本体ではない脆弱性 #### zlib CVE-2026-22184 の事例 2026年初頭、zlibに対しCVE-2026-22184（CVSS **9.3**）が登録された[^14]。問題点は以下のとおり。 - 脆弱性はzlibライブラリ**本体ではなく**、contrib/untgzというリファレンス実装（サンプルコード）に存在 - 多くのアプリケーションはzlibライブラリを使用しているが、このuntgzユーティリティを直接使用していない - GitHubのissueでこの点が指摘され、最終的にリファレンスコードは削除されたこの事例は、ライブラリ本体とサンプルコード/テストコードを区別しない脆弱性報告の問題を示している。 #### curl CVE-2023-52071 の事例匿名の報告者により登録されたこのCVEは、**デバッグビルドのみ**に存在するassert文における1バイトの境界外アクセスに関するものであった[^15]。 curlセキュリティチームの見解は以下のとおり。 - このコードはデバッグビルドにのみ含まれ、リリースビルドには存在しない - 最悪の場合クラッシュを引き起こすのみ - セキュリティ上の問題ではない本件は当初DISPUTEDとされたが、最終的に**REJECTED**に変更された。 ### 2.4 セキュリティスキャナーの誤検出 #### urllib3 の事例 urllib3は、セキュリティスキャンツールがSSLv2の使用を「安全でない」と検出したことによる報告を受けた[^16]。しかし、urllib3でのSSLv2の使用は、**明示的にSSLv2を無効化する**ためのものであった。この事例は、セキュリティスキャナーの結果を批判的思考なしに報告することの問題を示している。 ## 3. CVEシステムの構造的問題 ### 3.1 立証責任の逆転現行のCVEシステムでは、報告者に脆弱性の証明を厳密に求める仕組みがない。その結果、開発者側が「なぜこれが脆弱性ではないか」を証明する責任を負うことになる。 curl開発者のStenbergは以下のように批判している[^17]。 > The system is designed for good-faith reporters against bad-faith product organizations. So that bad companies cannot shut down whistleblowers basically. Instead it allows irresponsible or bad-faith reporters populate the CVE database with rubbish. > （参考訳：このシステムは、悪意ある製品組織に対する善意の報告者のために設計されています。基本的に、悪質な企業が内部告発者を黙らせることができないようにするためです。しかし、それは無責任または悪意ある報告者がCVEデータベースをゴミで埋め尽くすことを許しています。） ### 3.2 DISPUTED と REJECTED の障壁開発者が脆弱性の有効性に異議を唱えた場合、CVEレコードにはDISPUTEDタグが付与される。しかし、REJECTEDステータスへの変更は困難である。 MITREがcurl CVE-2020-19909の却下を拒否した際の回答は以下のとおり。 > After review there are multiple perspectives on whether the issue information is helpful to consumers of the CVE List, our current preference is in the direction of keeping the CVE ID assignment. > （参考訳：レビューの結果、この問題情報がCVEリストの利用者にとって有用かどうかについては複数の見解があり、現時点ではCVE IDの割り当てを維持する方向で検討しています。） ### 3.3 Linux Kernel CNA化とCVE洪水 2024年2月、Linux KernelプロジェクトがCVE Numbering Authority（CNA）として認定された。「すべてのバグ修正にCVEを割り当てる」方針により、CVE数が急増した[^18]。 | 年 | CVE数 | 増減 | |---|---:|---| | 2023年 | 290件 | - | | 2024年 | 3,529件 | 約13倍 | | 2025年1月（16日間） | 134件 | - | この「CVE洪水」は、セキュリティチームに「CVE疲れ」を引き起こし、真に重要な脆弱性を見逃すリスクを高めているとの批判がある。 ## 4. 影響の分析 ### 4.1 開発者への影響 | 影響 | 事例 | |------|------| | リポジトリのアーカイブ | node-ip（2024年6月） | | バグバウンティプログラムの終了 | curl（2026年1月） | | メンテナーの辞任 | libxml2（2025年9月） | | 精神的疲弊・バーンアウト | 多数のOSSプロジェクト | Seth Larsonは以下のように警告している[^19]。 > Wasting precious volunteer time doing something you don't love and in the end for nothing is the surest way to burn out maintainers or drive them away from security work. > （参考訳：貴重なボランティア時間を好きでもないことに費やし、結局何も得られないことは、メンテナーをバーンアウトさせたり、セキュリティ作業から遠ざけたりする最も確実な方法です。） ### 4.2 セキュリティエコシステムへの影響 1. **CVE疲れ**: 偽陽性の洪水により、真に重要な脆弱性が見逃されるリスク 2. **サプライチェーンへの波及**: npm audit等のツールが誤検出を報告し、下流プロジェクトに連鎖 3. **「狼少年」効果**: 繰り返される誤報により、CVEシステム全体の信頼性が低下 4. **リソースの浪費**: セキュリティチームが偽陽性の調査に時間を費やす ### 4.3 セキュリティ情報サイトの検証能力の問題 zlib CVE-2026-22184の事例では、多くのセキュリティ情報サイトがNVDの情報をほぼそのまま転載し、「zlibに深刻な脆弱性が見つかった」と報じた。しかし、これがライブラリ本体ではなくリファレンスコードの問題であることを独自に検証した記事は見当たらなかった。このような「垂れ流し」報道は、以下の問題を引き起こす。 - 誤った情報の世界的拡散 - 発見者と開発者間の不要な緊張 - エンドユーザーの混乱と不要なパッチ作業 ## 5. 各プロジェクトの対策 ### 5.1 curl プロジェクト | 対策 | 内容 | |------|------| | AI使用開示の義務化 | HackerOneレポートでAI使用のチェックボックスを追加（2025年5月） | | 即時バン方針 | AI slopと判断されたレポートの報告者を即時バン | | バグバウンティ終了 | 金銭的インセンティブを排除（2026年1月） | | CNA登録 | 独自にCVEを管理する権限を取得（2024年1月） | ### 5.2 Django プロジェクト security.txtに以下を追加[^20]。 - AI使用の開示義務 - 報告内容の検証義務 - 捏造コンテンツの排除 - 「人生の意味」についての段落を含めるよう要求（AI検出用カナリア） ### 5.3 Python Software Foundation Seth Larsonが推奨する対策[^21]。 **報告者向け**: - AI/LLMを脆弱性検出に使用しない（現状のAIはコードを理解できない） - 人間が検証したレポートのみ提出 - パッチを付けて報告する（レポートだけでなく） **メンテナー向け**: - AI生成と疑われるレポートには最小限の対応で閉じる - 「このレポートはAI生成/不正確/スパムと思われます。追加の正当化を提供してください」と返信 **プラットフォーム向け**: - 自動化または濫用的なレポート作成を防止するシステム（CAPTCHA、レート制限） - 脆弱性レコードを公開せずにレポートを公開できる機能（濫用者の「名前と恥」公開用） ## 6. セキュリティ業界の反応開発者側の対応（バグバウンティ終了、リポジトリアーカイブなど）に対し、セキュリティ企業およびセキュリティ業界からは様々な反応が示されている。 ### 6.1 バグバウンティプラットフォームの対応 #### HackerOne HackerOneは、開発者からの批判に対し、複数の対応を発表している。 **公式見解**（2025年5月、Alex Rice共同創業者/CTO/CISO）[^22] > HackerOne's Code of Conduct does not prohibit the use of AI to assist in writing reports — but it does prohibit spam. Reports that contain hallucinated vulnerabilities, vague or incorrect technical content, or other forms of low-effort noise will be strictly treated as spam and result in enforcement actions under our Code of Conduct. > （参考訳：HackerOneの行動規範はレポート作成にAIを使用することを禁止していませんが、スパムは禁止しています。幻覚された脆弱性、曖昧または不正確な技術的内容、その他の低品質なノイズを含むレポートは、スパムとして厳格に扱われ、行動規範に基づく執行措置の対象となります。） **AIの有用性を主張**（Michiel Prins、共同創業者/プロダクト管理シニアディレクター）[^23] > Overall, we're seeing an aggregate increase in report quality as AI helps researchers bring clarity to their work, especially where English is a second language. The key is ensuring that AI enhances the report rather than introducing noise. > （参考訳：全体として、AIが研究者の作業に明確さをもたらすのに役立つことで、特に英語が第二言語である場合に、レポート品質が総合的に向上しています。重要なのは、AIがノイズを導入するのではなく、レポートを強化することを確認することです。）ただし、同時に問題も認識している。 > We've also seen a rise in false positives — vulnerabilities that appear real but are generated by LLMs and lack real-world impact. These low-signal submissions can create noise that undermines the efficiency of security programs. > （参考訳：LLMによって生成され、現実世界での影響がない、本物に見える脆弱性という偽陽性の増加も見られます。これらの低シグナル提出は、セキュリティプログラムの効率を損なうノイズを生み出す可能性があります。） **Hai Triage の発表**（2025年7月22日）[^24] HackerOneは、AI slop問題への対策として「Hai Triage」を発表した。これはAIエージェントと人間のアナリストを組み合わせたトリアージシステムである。 > Hai Triage uses AI agents and human-in-the-loop oversight to cut through the noise, automatically filtering duplicates, spam, and informative findings so your team can get to work on threats with real impact. > （参考訳：Hai TriageはAIエージェントとヒューマン・イン・ザ・ループの監視を使用してノイズを切り抜け、重複、スパム、情報提供的な発見を自動的にフィルタリングし、チームが実際に影響のある脅威に取り組めるようにします。）この対応について、あるコメンターは皮肉を込めて「AIでAIを戦う（fire with fire）」と表現している[^25]。 #### Bugcrowd Bugcrowdの創業者Casey Ellisは、比較的楽観的な見解を示している[^26]。 > AI is widely used in most submissions, but it hasn't yet caused a significant spike in low-quality 'slop' reports. This'll probably escalate in the future, but it's not here yet. > （参考訳：AIはほとんどの提出で広く使用されていますが、まだ低品質な「slop」レポートの大幅な増加を引き起こしていません。おそらく将来的にはエスカレートするでしょうが、まだそこには至っていません。） Bugcrowdでは週に500件の提出増加を見ているが、既存のプレイブックとワークフロー、および機械学習とAIの「支援」を使用して手動でレビューしているとのことである。 ### 6.2 脆弱性データベース企業への批判 #### node-ip開発者によるSnykへの批判 node-ipの開発者Fedor Indutnyは、Snykを名指しで批判した[^27]。 > It looks like there are entities that in theory should fill the void in OSS community and provide resources for managing security reports for overloaded maintainers. (I'm looking at you SNYK) > （参考訳：理論的には、OSSコミュニティの空白を埋め、過負荷のメンテナーのためにセキュリティレポートを管理するリソースを提供すべきエンティティがあるようです。（SNYKを見ています）） > However, the verification process of vulnerability reports doesn't involve maintainer at all, and it sounds like the commercial interest of advisory repositories is aligned with creating more vulnerabilities and proving themselves 'useful' to companies that utilize them. > （参考訳：しかし、脆弱性レポートの検証プロセスにはメンテナーが全く関与しておらず、アドバイザリリポジトリの商業的利益は、より多くの脆弱性を作成し、それを利用する企業に対して「有用」であることを証明することと一致しているように聞こえます。）この批判は、セキュリティベンダーのビジネスモデル自体が「より多くの脆弱性を報告するインセンティブ」を生み出しているという構造的問題を指摘している。 #### Stacklokエンジニアの分析 StacklokのソフトウェアエンジニアEvan Andersonは、Software Supply Chain Security Weeklyニュースレターで以下のように分析している[^28]。 > The CVE in question was marginal (it involved passing a user-controlled IP address string in a security decision context), but the tooling for flagging CVEs in npm dependencies caused a huge amount of noise and chaos for the project for minimal security benefit. > （参考訳：問題のCVEは限界的なものでした（セキュリティ決定コンテキストでユーザー制御のIPアドレス文字列を渡すことに関係していました）が、npm依存関係でCVEをフラグ付けするツールは、最小限のセキュリティ上の利益のためにプロジェクトに大量のノイズと混乱を引き起こしました。） > Clout-chasing in the vulnerability research world has real consequences for maintainers. > （参考訳：脆弱性研究の世界での名声追求は、メンテナーに実際の影響をもたらします。） ### 6.3 大手テック企業の沈黙 TechCrunchの取材に対し、MetaとMicrosoftはコメントを拒否し、Googleはコメント要請に応答しなかった[^29]。これらの企業はAIに大規模な投資を行っており、かつ自社でバグバウンティプログラムを運営しているが、AI生成レポートの問題についての公式見解は示していない。一方、Mozillaは以下のように回答している。 > We have not seen a substantial increase in invalid or low-quality bug reports that would appear to be AI-generated. The rejection rate has remained steady at five or six reports per month, or less than 10% of all monthly reports. > （参考訳：AI生成と思われる無効または低品質なバグレポートの大幅な増加は見られていません。却下率は月に5〜6件、つまり月間全レポートの10%未満で安定しています。） Mozillaはまた、「レビュー担当者はAIフィルターを使用していない。正当なバグレポートを誤って却下するリスクがあるため」と述べている。 ### 6.4 セキュリティ研究者コミュニティの反応 curlのPull Requestコメント欄には、セキュリティ研究者からの様々な反応が寄せられている[^30]。 **バグバウンティ業界への危機感** > That's a disgrace for the bug bounty industry. I'm sorry of the quality you received with your program, and I'm worried about the future of my industry, considering the platforms' behavior with low quality hunters. > （参考訳：これはバグバウンティ業界の恥です。あなたのプログラムで受け取った品質については申し訳なく思いますし、低品質のハンターに対するプラットフォームの行動を考えると、私の業界の将来が心配です。） **構造的問題の指摘** > Shutting down the program feels more like treating the symptom than the disease. The real problem is the breakdown in signal-to-noise and the lack of accountability for low-quality submissions. > （参考訳：プログラムを終了することは、病気ではなく症状を治療しているように感じます。本当の問題は、シグナル対ノイズの崩壊と低品質な提出に対する説明責任の欠如です。） **AI使用の適切な方法の提示** ある経験豊富なセキュリティ研究者は、自身もAIをコードレビュー支援に使用しているが、以下のように述べている。 > I also submitted no reports on HackerOne because I didn't find any valid issues which crossed any meaningful security boundary. Oh, AI tends to disagree of course. It found five different paths to "🚨CRITICAL RCE 🚨" in nearly one out of ten files it audited. Doesn't matter which LLM you ask. The difference is in HOW you use it and how much you depend on it. > （参考訳：私もHackerOneにレポートを提出しませんでした。意味のあるセキュリティ境界を越える有効な問題を見つけられなかったからです。もちろん、AIは反対する傾向があります。監査したファイルの約10分の1で、「🚨CRITICAL RCE🚨」への5つの異なるパスを見つけました。どのLLMに尋ねても同じです。違いは、どのように使用するか、どれだけ依存するかにあります。） ### 6.5 HackerOne現役社員の個人的見解 HackerOneのトリアージチームリーダー（5年勤務）は、個人ブログで以下のように述べている[^31]。 > I have now spent almost a decade in the bug bounty industry... I have now almost developed an instinct that tells me if a report is BS or a valid security concern just by looking at it. > （参考訳：私はバグバウンティ業界でほぼ10年を過ごしてきました...今では、レポートを見ただけでそれがBSか有効なセキュリティ上の懸念かを教えてくれる直感をほぼ身につけました。） > I have seen cases where it was almost impossible to determine whether a report was a hallucination or a real finding. Even my instincts and a decade of experience failed me, and this is honestly frustrating. > （参考訳：レポートが幻覚なのか本当の発見なのかを判断することがほぼ不可能なケースを見てきました。私の直感と10年の経験さえも私を裏切りました。これは正直言って frustrating です。）この証言は、問題がプラットフォームの内部でも認識されていることを示している。 ### 6.6 業界反応の分析セキュリティ業界の反応を分析すると、以下のパターンが見られる。 | 立場 | 反応 | 特徴 | |------|------|------| | バグバウンティプラットフォーム | 問題認識しつつもAIの有用性を強調、技術的対策（AI triage）を発表 | 自社ビジネスモデルへの影響を考慮 | | 脆弱性データベース企業 | 公式には沈黙（Snykは批判に応答せず） | 商業的利益との関係を指摘される | | 大手テック企業 | コメント拒否 | AI投資と自社バグバウンティ運営の両面を持つ | | セキュリティ研究者 | 問題を認識、業界の将来に危機感 | 自身の職業への影響を懸念 | 特筆すべきは、**批判を受けた側（HackerOne、Snyk等）からの直接的な反論や謝罪がほとんど見られない**ことである。HackerOneは「AI使用は禁止しないがスパムは禁止」という立場を維持しつつ、技術的対策（Hai Triage）で対応しようとしている。Snykはnode-ip開発者からの批判に対し、公式には応答していない。この「沈黙」は、セキュリティ業界のビジネスモデル（脆弱性を多く発見・報告することが価値を生む）と、開発者の利益（真に重要な脆弱性のみに集中したい）の間に、構造的な利益相反が存在することを示唆している。 ## 7. 考察 > **注記**: 本セクションは、第2章〜第6章の調査結果に基づく筆者の考察・意見であり、事実の報告ではない。 ### 7.1 脆弱性情報の「信頼性」本調査を通じて明らかになったのは、CVEシステムおよびそれに依存するセキュリティエコシステムにおける**信頼性の構造的問題**である。現状では、以下の非対称性が存在する。 | 側 | 責任 | 能力 | |---|---|---| | 報告者 | 証明責任なし | 当該ソフトウェアへの理解は限定的 | | 開発者 | 「脆弱性ではない」ことの証明責任 | 自身のソフトウェアを最もよく理解 | | NVD | CVSSスコアの付与 | 個別の脆弱性を深く検証する能力は限定的 | | メディア | 情報の伝達 | 独自検証能力は限定的 | ### 7.2 「適度な非効率」の観点から現在のCVEシステムは**過度な効率化**の弊害を示していると考える。 - 誰でも低コストでCVEを報告できる「効率的」なシステム - 結果として、ノイズが増大しシグナルが埋もれる - 真に重要な脆弱性への対応が遅れるリスク CVEシステムには、報告に一定の「摩擦」を設けることで品質を担保する仕組み（適度な非効率）が必要かもしれない。 ### 7.3 発見者と開発者の合意の重要性本調査で取り上げた問題事例の多くは、**発見者と開発者の間で合意がない**状態で脆弱性が公開されたケースである。脆弱性情報の品質保証は、以下の理由から発見者と開発者の双方が担うべきである。 - 開発者は脆弱性への想像力において発見者に劣る（だから発見者という存在が必要） - 発見者は当該ソフトウェアの理解において開発者に劣る（だから的外れな発見もあり得る） - 双方が合意に至った脆弱性こそが、対策する価値のある脆弱性である ### 7.4 OSSエコシステムにおける「対等な対話」の喪失本調査で明らかになった問題の根底には、OSSエコシステムにおける**対等な対話の喪失**がある。 #### Log4Shellに見る「善意の暴力」 2021年12月に公開されたLog4Shell（CVE-2021-44228）は、Apache Log4jの重大な脆弱性として世界中に影響を与えた。このとき、Log4jのメンテナーたち—多くがボランティアで、本業の傍らでこの重要なインフラを支えていた人々—は、時間を割いて対応に当たっていた。しかし彼らに浴びせられたのは、「いつ直るのか」「うちのシステムが止まったらどうしてくれる」という言葉であった。これは**善意の暴力**とも呼ぶべき現象である。OSSの仕組みを知らない、ボランティアが支えていることを知らない人々が、「自分のシステムが危ない」という恐怖から、最も近くにいる「責任者らしき人」に怒りをぶつける。彼らは自分がセキュリティを「守っている」つもりだったかもしれない。しかし実際には、セキュリティを支える人々を傷つけていた。 #### 「消費者」としての振る舞い問題の本質は、OSSに対して**消費者として振る舞う**姿勢にある。 - 普段は存在すら意識しない基盤（OSSライブラリ）が、当然のように機能することを前提にする - 問題が起きたときだけ「責任者を出せ」と叫ぶ - しかしメンテナーに給料を払っていたわけでも、感謝を伝えていたわけでもない「npm install」一つで数百の依存が入る時代に、すべてを自分で品質保証することは確かに困難である。しかしそれは、**責任が消えることを意味しない**。把握できないなら、把握できないことを認識した上でリスクを受け入れるか、使わないか、あるいは把握できる範囲で使うか—それを選択する責任は残り続ける。今回調査した問題の根底にあるのは、この「選択としての責任」の喪失である。OSSを空気のように使い、問題が起きたら誰かのせいにする。CVEが出たら「開発者が直すべき」と考え、CVSSが高ければ「緊急だ」と騒ぐ。そこには「対話」も「対等」もない。 ### 7.5 「異文化との対話」という視点サイバーセキュリティにおける諸々の問題の一端は、**異文化との対話不足**にあるのかもしれない。 #### 異なる「文化」を持つ当事者たち今回の調査で登場した当事者は、それぞれ異なる「文化」を持っている。 | 当事者 | 文化・価値観 | |--------|------------| | OSS開発者 | コードで語る。問題があればパッチを送る。対等な立場で協力する | | セキュリティ研究者 | 脆弱性を発見し、報告し、公開する。CVEとCVSSという「言語」で深刻度を伝える | | 企業セキュリティ部門 | リスクを管理し、コンプライアンスを満たす。監査で指摘されないことが重要 | | バグバウンティハンター | 報奨金というインセンティブ。効率よく「発見」を量産する | これらの文化は、本来は補完的であり得るはずである。しかし現状では、それぞれが自分の言語で一方的に話し、相手の文脈を理解しようとしない。 #### CVSSは「振りかざす武器」ではなく「対話の道具」 CVSSは本来、「共通言語」として設計された。Base Scoreという「一般論」を起点に、「あなたの環境ではどうか」を対話するためのEnvironmental Metricsが用意されている。しかし現実には、Base Scoreだけが一人歩きし、対話のプロセスが省略されている。CVSSは「このスコアだから直せ」と命令するためのものではなく、「この観点からはこう評価される」という**対話の起点**を提供するものであるはずだ。 - 発見者が「攻撃者の視点」を提供する - 開発者が「ソフトウェアの文脈」を提供する - 両者が対話することで「この環境では本当に危険か」「どう修正すべきか」が見えてくる CVSSをベースに、発見者と開発者が対等の立場で対話して、脆弱性の解決に導く—これが本来のあり方である。 ### 7.6 「共通了解」の構築とセキュリティ専門家の役割 #### 「独断」「信念対立」「共通了解」哲学的な枠組みを借りれば、本調査で見えた問題は「独断」と「信念対立」の問題として整理できる。 - **独断**: 自分の信念を、検証なく正しいと思い込む - **信念対立**: 異なる信念を持つ者同士が、相手を理解しようとせず対立する - **共通了解**: 異なる信念を持つ者同士が、対話を通じて相互に了解可能な地点を見出す今回の調査で見えた問題を、この枠組みで捉え直すと： - AI slop報告者は、開発者の信念（コードの文脈、実際の影響）を**了解しようとすらしていない** - CVSSを振りかざす人々は、「CVSSが高い＝直すべき」という自分の信念を**押しつけている** - Log4jで詰め寄った人々は、OSSコミュニティの信念を**了解せず**、商用サポートの信念で接しているいずれも「信念対立」のまま、「共通了解」に至るプロセスが欠落している。 #### 「同意」ではなく「了解」ここで重要なのは、**「同意」と「了解」は異なる**ということである。 - 「同意」: 相手の意見に賛成する - 「了解」: 相手がなぜそう考えるかを理解する（賛成・反対は別として）分かり「合える」ことを無理して目指す必要はない。相手の考え（信念）について、同意・不同意ではなく「了解」できれば良い。例えば： - セキュリティ専門家は、CVSSスコアを重視している（そういう信念を持っている） - 開発者は、真に修正すべき脆弱性に集中したい（そういう信念を持っている）これを、どちらかの意見に寄せる（押しつける）のではなく、お互いに相手の考え（信念）を**了解した上で**、では、どのように問題を解決するのかを考える。 #### セキュリティ専門家の役割の再定義この視点に立つと、セキュリティ専門家に求められる能力は、「異なる信念を持つ相手と対話し、共通了解を構築する能力」と言える。そして、セキュリティ専門家の役割は、実は**問題を解決する人ではない**。 **「何を解決すべきなのか、その目線を合わせられる人」**である。「問題を解決する人」であれば、技術的知識が中心になる。しかし「目線を合わせられる人」であれば、求められるのは： - 開発者の信念を了解する力（コードの文脈、設計意図、リソース制約） - 経営者の信念を了解する力（事業継続、コスト、レピュテーション） - 攻撃者の信念を了解する力（動機、能力、機会） - そして、これらの間で「では何を解決すべきか」を共に見出す対話の力これは「翻訳者」や「外交官」に近い役割である。異なる文化、異なる言語、異なる利害を持つ当事者の間に立ち、共通了解を構築していく。本調査で明らかになった問題—AI slop、誇張されたCVSS、開発者の疲弊—は、この「対話」と「共通了解」の欠如から生じている。技術的な対策（AIフィルター、プラットフォーム改善）も重要だが、より本質的には、サイバーセキュリティに関わるすべての当事者が「異文化との対話」の姿勢を取り戻すことが必要なのかもしれない。 ## 8. 推奨事項 ### 8.1 脆弱性情報の受信者向け 1. **一次情報源の確認**: NVDだけでなく、開発者のセキュリティアドバイザリやGitHub issueを確認 2. **CVEステータスの確認**: DISPUTED、REJECTEDのタグが付いていないか確認 3. **影響範囲の精査**: ライブラリ本体か、サンプルコード・テストコードかを区別 4. **CVSSスコアの批判的評価**: スコアだけでなく、攻撃ベクトルや前提条件を詳細に確認 5. **複数情報源の参照**: NVD、ベンダーアドバイザリ、セキュリティ研究者の分析を比較 ### 8.2 組織向け 1. **脆弱性トリアージプロセスの確立**: 自動スキャン結果を鵜呑みにしない 2. **脆弱性の「信頼度」評価の導入**: 開発者の見解、DISPUTEDステータス等を考慮 3. **セキュリティ情報サイトの選別**: 独自検証能力を持つ情報源を優先 ### 8.3 CVEエコシステム向け 1. **報告者への証明責任の付与**: 再現手順、悪用シナリオの提示を義務化 2. **開発者意見の尊重**: 当該ソフトウェアを最もよく知る開発者の見解を重視 3. **REJECTEDへの障壁低下**: 明らかな誤報の迅速な排除を可能に 4. **AI生成レポートへの対策**: プラットフォームレベルでの検出・制限 ## 9. まとめ実態と乖離した脆弱性報告は、オープンソースエコシステムにおいて深刻な問題となる。AI/LLMの普及により低品質レポートの生成が容易になったこと、CVEシステムの構造的問題（立証責任の逆転、REJECTEDへの高い障壁）、セキュリティ情報サイトの検証能力の限界などが、問題を悪化させている。しかし、より本質的な問題は、**異文化間の対話の欠如**にある。OSS開発者、セキュリティ研究者、企業セキュリティ部門、バグバウンティハンター—それぞれが異なる文化と価値観を持ちながら、相手の文脈を理解しようとせず、自分の言語で一方的に話している。CVSSは「対話の道具」として設計されたにもかかわらず、「振りかざす武器」と化している。この問題への対処には、技術的な対策（AIフィルター、プラットフォーム改善、CVEシステムの改革）と同時に、関係者全員が「異文化との対話」の姿勢を取り戻すことが必要である。セキュリティ専門家の役割もまた、再考されるべきかもしれない。セキュリティ専門家とは、単に「問題を解決する人」ではなく、**「何を解決すべきなのか、その目線を合わせられる人」**である。異なる信念を持つ当事者の間に立ち、「同意」ではなく「了解」を基盤として、共通了解を構築していく—それは「翻訳者」や「外交官」に近い役割である。 CVEやCVSSスコアは有用な指標ではあるが、絶対的な真実ではない。開発者の見解、実際の悪用可能性、自組織の環境への適用可能性を総合的に判断し、そして何より、異なる立場の当事者と**対等な対話**を通じて脆弱性の解決に導くこと—それが、サイバーセキュリティにおける真の専門性なのかもしれない。 --- ## 脚注 [^1]: Seth Larson, "New era of slop security reports for open source", https://sethmlarson.dev/slop-security-reports (アクセス日: 2026-01-23) [^2]: BleepingComputer, "Curl ending bug bounty program after flood of AI slop reports", https://www.bleepingcomputer.com/news/security/curl-ending-bug-bounty-program-after-flood-of-ai-slop-reports/ (アクセス日: 2026-01-23) [^3]: Daniel Stenberg, GitHub PR "BUG-BOUNTY.md: we stop the bug-bounty", 2026年1月 [^4]: The Register, "Open source maintainers are drowning in junk bug reports written by AI", https://www.theregister.com/2024/12/10/ai_slop_bug_reports/ (アクセス日: 2026-01-23) [^5]: Socket.dev, "Django Joins curl in Pushing Back on AI Slop Security Reports", https://socket.dev/blog/django-joins-curl-in-pushing-back-on-ai-slop-security-reports (アクセス日: 2026-01-23) [^6]: GIGAZINE, "GoogleによるAIを用いた大量バグ報告にFFmpegが苦言", https://gigazine.net/news/20251112-ffmpeg-google/ (アクセス日: 2026-01-23) [^7]: GNOME Discourse, "Stepping down as libxml2 maintainer", https://discourse.gnome.org/t/stepping-down-as-libxml2-maintainer/31398 (アクセス日: 2026-01-23) [^8]: GIGAZINE, "オープンソースツール「node-ip」の軽度な脆弱性が「緊急対応を要する重大な脆弱性」として報告され連絡が殺到し開発者がリポジトリを一時アーカイブ", https://gigazine.net/news/20240702-node-ip-repository-archive/ (アクセス日: 2026-01-23) [^9]: BleepingComputer, "Dev rejects CVE severity, makes his GitHub repo read-only", https://www.bleepingcomputer.com/news/security/dev-rejects-cve-severity-makes-his-github-repo-read-only/ (アクセス日: 2026-01-23) [^10]: GIGAZINE, "脆弱性にIDを割り振って管理する「CVE」のシステムには欠陥があるという指摘", https://gigazine.net/news/20230829-wrong-with-cves/ (アクセス日: 2026-01-23) [^11]: Daniel Stenberg, "CVE-2020-19909 is everything that is wrong with CVEs", https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/ (アクセス日: 2026-01-23) [^12]: GitHub Advisory, "CVE-2024-4067 - Regular Expression Denial of Service (ReDoS) in micromatch", https://github.com/advisories/GHSA-952p-6rrq-rcjv (アクセス日: 2026-01-23) [^13]: Socket.dev, "node-ip Maintainer Restores GitHub Repo After Archiving Due to Overblown CVE Rating", https://socket.dev/blog/node-ip-maintainer-restores-github-repo-after-archiving-due-to-overblown-cve-rating (アクセス日: 2026-01-23) [^14]: GitHub - zlib Issue #1142, https://github.com/madler/zlib/issues/1142 (アクセス日: 2026-01-13) [^15]: curl - CVE-2023-52071, https://curl.se/docs/CVE-2023-52071.html (アクセス日: 2026-01-13) [^16]: Seth Larson, "New era of slop security reports for open source", 同上 [^17]: Daniel Stenberg, "DISPUTED, not REJECTED", https://daniel.haxx.se/blog/2024/02/21/disputed-not-rejected/ (アクセス日: 2026-01-13) [^18]: TuxCare, "The Linux Kernel CVE Flood Continues Unabated in 2025", https://tuxcare.com/blog/the-linux-kernel-cve-flood-continues-unabated-in-2025/ (アクセス日: 2026-01-13) [^19]: The Register, "Open source maintainers are drowning in junk bug reports written by AI", 同上 [^20]: Django Security Documentation, security.txt更新（2025年） [^21]: Seth Larson, "New era of slop security reports for open source", 同上 [^22]: The New Stack, "Curl Fights a Flood of AI-Generated Bug Reports From HackerOne", https://thenewstack.io/curl-fights-a-flood-of-ai-generated-bug-reports-from-hackerone/ (アクセス日: 2026-01-23) [^23]: TechCrunch, "AI slop and fake reports are coming for your bug bounty programs", https://techcrunch.com/2025/07/24/ai-slop-and-fake-reports-are-exhausting-some-security-bug-bounties/ (アクセス日: 2026-01-23) [^24]: HackerOne, "HackerOne Unveils Hai Triage: Upgraded AI-Powered Vulnerability Response", https://www.hackerone.com/press-release/hackerone-unveils-hai-triage-upgraded-ai-powered-vulnerability-response (アクセス日: 2026-01-23) [^25]: HackerOne内部関係者による個人ブログ, "On AI Slop vs OSS Security", https://devansh.bearblog.dev/ai-slop/ (アクセス日: 2026-01-23) [^26]: TechCrunch, "AI slop and fake reports are coming for your bug bounty programs", 同上 [^27]: Socket.dev, "node-ip Maintainer Restores GitHub Repo After Archiving Due to Overblown CVE Rating", 同上 [^28]: Evan Anderson, Software Supply Chain Security Weekly Newsletter [^29]: TechCrunch, "AI slop and fake reports are coming for your bug bounty programs", 同上 [^30]: GitHub, curl/curl Pull Request #20312, https://github.com/curl/curl/pull/20312 (アクセス日: 2026-01-23) [^31]: HackerOne内部関係者による個人ブログ, "On AI Slop vs OSS Security", 同上