curl作者がクローズドの「Mythos」による17万8000行のコード分析結果を公開 性能をどう評価?:「パニックになるほど危険ではない」
「curl」プロジェクトの開発者であるダニエル・ステンバーグ氏は、AnthropicのAIモデル「Mythos」による脆弱性分析レポートを受領し、その結果を共有した。
「curl」プロジェクトの開発者であるダニエル・ステンバーグ氏は2026年5月11日(スウェーデン時間)、自身のブログで、AnthropicのAIモデル「Mythos」によるcurlソースコードの脆弱(ぜいじゃく)性分析の結果を共有した。curlは、URLを使ってコマンドラインからデータを送受信できるオープンソースツールだ。
ステンバーグ氏は当初、The Linux Foundationの「Alpha-Omega」プロジェクトを通じて同モデルへのアクセス権を付与される予定だった。しかし手続きに遅れが生じたため、最終的にはすでにアクセス権を持っていた別の人物が代理でcurlのソースコードをスキャンし、そのレポートを同氏が受け取ったという。
すでに200件超のバグを修正 curlプロジェクトにおけるAIコード分析のリアル
curlプロジェクトでは、Mythos以前から複数の高機能なAI支援ツールでコード分析を実施してきた。AIコード分析ツール「AISLE」「Zeropath」「OpenAI Codex Security」を利用しており、これらの分析結果に基づいて、過去8〜10カ月で200〜300件のバグ修正がcurlにマージされた。確認された脆弱性も多数あり、CVE(共通脆弱性識別子)として公開されたものは十数件に及ぶ。
プルリクエストレビューにはAIコーディング支援ツール「GitHub Copilot」や「Augment Code」を導入しており、AIによる指摘が新規バグの混入を防ぐ補助となっている。「AIレビューは人間のレビューを置き換えるものではなく、補完するものとして機能している」と、ステンバーグ氏は説明している。
セキュリティ研究者からの脆弱性報告も、AIの活用によって質や量の両面で増加している。「セキュリティはcurlプロジェクトにとって最優先事項だ」「欠陥スキャンはコード品質を保つ多くのステップの一つに過ぎない」とステンバーグ氏はコメントしている。
「パニックになるほど危険ではない」 クローズドなMythosの性能を評価
ステンバーグ氏によると、Mythosによる初回スキャンの結果を受け取ったのは、2026年5月6日のこと。スキャンはcurlのgitリポジトリのマスターブランチを対象に実行され、src/およびlib/サブディレクトリの17万8000行のコードを分析した。
Mythosは「確認済みのセキュリティ脆弱性」として5件を報告した。レポート冒頭には次のような注記があったという。
「curlは現存する中で最もファジング(Fuzzing)テストと監査を受けたC言語コードベースの一つであり、HTTP/1、TLS、URL解析コア(中核処理)といった重点的にテストされている領域から何か見つかる可能性は低い」
事実、これらに関する問題は検出されなかったという。curlセキュリティチームが詳細を精査した結果、最終的に確認済み脆弱性として残ったのは1件のみとなった。残り4件のうち3件はAPIドキュメントに記載されている既知の制約を脆弱性と誤認した「フォールスポジティブ」(偽陽性)であり、1件は「単なるバグ」と判断された。
確認された1件の脆弱性は深刻度「低」のCVEとして、curl 8.21.0のリリースに合わせて2026年6月下旬に公開予定だ。「世間がパニックに陥るような深刻な問題ではない」とステンバーグ氏は説明している。
レポートには、脆弱性ではないバグも約20件記載され、curlチームが順次対応している。ステンバーグ氏は「誤検知はほとんどなく、報告内容の解説も非常に的確だった。Mythosが問題を報告する際、確実にバグだと判断したもののみを報告するよう調整されているのだろう」と推測している。
検出数だけを見ると、curlがこれまで利用した他のAIツールの方が多くのバグを発見している。これは初期に利用したツールほど見つけやすいバグが残っていたためであり、修正が進むにつれて新規バグの発見は徐々に難しくなるためだとした。
ステンバーグ氏は、Mythosを巡る話題はマーケティング先行の側面が強いと結論付ける。「他のAIツールがこれまで見つけてきたものと比べて、Mythosが特に高度な、あるいは特殊な問題を見つけているという証拠はない」「少し優れているかもしれないが、コード分析に大きな変化をもたらすほどの差ではない」と評価している。
ただし対象は今回curlだけであり、他の領域では結果が異なる可能性があることも付け加えている。
AIコード分析ツールが優れる理由
一方でステンバーグ氏は、AI搭載のコード分析ツールが従来の静的解析ツールより本質的に優れている点も改めて強調する。「最新のAIモデルはコード分析にたけている。時間と実験する気があれば、誰でもセキュリティ問題を発見できる」と述べ、AIツールを導入していないプロジェクトは、攻撃者に「自分たちが見つけられなかった脆弱性」を発見し、悪用(エクスプロイト)する時間と機会を与えてしまっていることになると警鐘を鳴らしている。
同氏は、AI分析ツールが従来の静的解析ツールよりも優れている特徴として、以下の6つを挙げている。
コメントと実装の食い違いを検出できる
コメントが説明する動作と、実際のコード動作が一致しない場合を見抜ける。従来の静的解析ツールはコード自体の不整合は検出できても、ドキュメントとの食い違いまでは判定できなかった。
通常の解析ツールでは対応できないプラットフォームや構成を検査できる
従来の分析ツールが検査できなかった環境のコードもチェックできる。ビルド構成やプラットフォーム依存のコードパスまで踏み込んだ分析が可能になっている。
サードパーティーライブラリのAPI仕様を「知っている」
外部ライブラリの詳細を把握しているため、不適切な使用や誤った前提を検出できる。AIモデルが学習段階で吸収した広範なライブラリ知識が、コードレビュー時に活用される。
プロトコル仕様との不整合を検出できる
curlが実装するプロトコルの詳細を「知っている」ため、仕様に違反する実装を指摘できる。HTTP、TLS、FTPなどの仕様書に書かれた挙動と実装のずれを発見する用途で有効だ。
欠陥の要約と説明が得意
従来の分析ツールでは難しかった、欠陥内容を読みやすく要約・説明する能力に優れる。開発者がレポートを読み解く時間を短縮でき、修正対応の迅速化につながる。
修正パッチ(修正プログラム)の生成を提案できる
発見した問題に対するパッチを自動生成できる場合がある。ただし完全な修正でないことが多く、開発者による検証と調整が前提となる。
ステンバーグ氏は、これまでAIツールが発見する欠陥は既知のタイプの新しい事例であり、「全く新種」「分野そのものを再発明する」ような脆弱性は今のところ報告されていないと指摘している。
「AIは新しい欠陥カテゴリーを発見できているわけではない。だが、従来のツールより多くの既知パターンの問題を発掘できているのは事実だ」
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
AIコーディングはなぜ後から苦しくなるのか? 技術負債に続く「理解負債」「認知負債」という新たな落とし穴
AIコーディングが普及する中で注目され始めた「理解負債」と「認知負債」。従来の技術負債と合わせた「AIコーディング時代の三大負債」を整理し、なぜ開発が後から苦しくなるのかを分かりやすく解説する。
なぜAIによるエンジニア代替はうまくいかないのか? “効率化”のはずが、現場で起きている逆転現象
AIで開発は効率化したはずだった。ところが現場では、品質低下やベテランの疲弊といった想定外の問題が広がっている。AI時代の開発現場で何が起きているのかを読み解く。
「もはやコーディングの80%がAI」 元OpenAIカルパシー氏が警告する2026年の悪夢“スロポカリプス”
OpenAIの初期メンバーであるアンドレイ・カルパシー氏が、自身の開発スタイルが数週間で劇変した事実と、2026年に訪れる「低品質コンテンツの氾濫」についての見解を公開した。AI時代のエンジニアの在り方を問う重要な警鐘だ。
なぜ「セキュリティのシフトレフト」が下火になったのか、ネガティブじゃないその理由 Dockerが解説
Dockerは、「The 2025 Docker State of Application Development Report」の中から、セキュリティに関する調査結果の概要を抜粋し、ブログで紹介した。
