Curlプロジェクトの保守担当者、ダニエル・ステンバーグ氏は、人工知能の支援を受けて作成されたという理由だけで、オープンソースのチームが脆弱性報告を退けることは、もはやできないと述べている。curlのセキュリティ対応の負担について新たに記した文章で、同氏は、課題が明らかな捏造報告から、技術的に信頼できるものの過度に長い報告の大量流入へ移ったと主張した。

ステンバーグ氏は、AIの支援を受けた内容を一律に「スロップ（低品質な生成物）」として無視するよう求める声に反対する。一部の報告は実際のバグや脆弱性を指摘しており、発見に用いたツールを理由に実証された欠陥を捨て置けば、利用者を危険にさらしたままになると記している。curlにはすべての不具合の修正を約束する一般的な法的保証はない。しかし、これまでの品質実績と、curl関連サービスを販売する貢献者が負うサポート上の義務が、信頼できる発見を調査する強い動機となっている。

この状況は、以前のAI生成報告の波とは異なる。ステンバーグ氏によると、AIの幻覚に基づく報告や明らかに誤った報告は、2026年春以降まれになった。過去数カ月間、curlには数百件の脆弱性報告が寄せられ、同氏は、そのすべてに何らかの形でAIが関与していると考えている。したがって、現在のボトルネックは、明らかに無意味な報告を除外することではなく、レビューできる量にある。

報告の品質は、書き方や分類の点で依然としてばらつきがある。AI支援の報告は数百行に及ぶことが多く、説明を繰り返し、人間の報告者なら冒頭で要約できる核心部分を分かりにくくする。また、AIシステムは通常のソフトウェアのバグとセキュリティ上の脆弱性を区別したり、適切な深刻度を判定したりすることを苦手としている。ステンバーグ氏は、人間の研究者も分類を誤るため、保守担当者による独自の評価は引き続き必要だと指摘する。

改善している点もある。報告された挙動の再現だ。最近の報告には、問題を引き起こす有効な概念実証プログラムや、信頼できる再現手順が含まれることが多い。周辺の文章を大幅に整理・精査する必要がある場合でも、このような証拠は、主張が事実かどうかを保守担当者が判断する助けになる。再現手段の作成は従来、脆弱性研究の中でも難しい作業だったが、今ではAIツールが報告者による迅速な作成を支援できる。

Curlの経験は、広く使われるオープンソースプロジェクトに生じつつある圧力を示している。自動化は、欠陥の可能性を探して報告を書くコストを下げるが、影響を検証し、深刻度を確定し、安全な修正を調整するために必要な、信頼できる人間の判断まで提供するわけではない。この不均衡により、保守チームが使える時間は増えないまま、より多くの有用な情報が流れ込む可能性がある。

ステンバーグ氏の対応は、あらゆるAIツールや報告を支持するものではない。証拠を扱うための実務的な原則であり、再現可能なセキュリティ上の問題は、発見方法にかかわらず重要だということだ。curlにとって、より難しい課題は、急速に増える機械支援の分析から、簡潔で対応可能な発見を抽出する持続可能な方法を作ることにある。