ツールチェーンが標的になる:エージェント時代のソフトウェア開発セキュリティ

eSecurity Planet のコンテンツおよび製品レコメンデーションは編集上独立しています。パートナーへのリンクをクリックいただくことで、当社が収益を得る場合があります。 詳細はこちら

私はキャリアの大半において、ソフトウェアサプライチェーンのセキュリティとは、開発者が取り込むもの、すなわち依存関係、ベースイメージ、サードパーティ製パッケージを精査することだと考えてきました。

しかし、その捉え方はもはや危険なほど不十分になっています。

この1年で、攻撃者はより上流へと移動し、パッケージを通り越して、開発者がそもそもコードを書くために使うツール自体を狙うようになりました。

IDE拡張機能、AIコーディングアシスタント、Model Context Protocol(MCP)サーバーは、今や標準的な開発者インフラです。

これらはコードベース、認証情報、CI/CDパイプラインへのアクセス権を保持しています。そして、既存のセキュリティフレームワークの大半は、そもそもこれらを可視化する設計になっていませんでした。

これは仮説ではなく、構造的な変化です。JFrogの「2026年版ソフトウェアサプライチェーンセキュリティ現状報告」によると、AI・MLライブラリを積極的に利用している組織の割合は41%に達し、1年前の34%から増加しています。また、平均的な組織が管理するこれらのパッケージ数は、前年比で47%増加しています。

サプライチェーンは単にAIというカテゴリーを追加しただけではありません。今やAIそのものがサプライチェーンになりつつあるのです。

要点

  • 開発者向けツールがソフトウェアサプライチェーンの一部となっており、IDE拡張機能、MCPサーバー、AIモデル、エージェントスキルが新たな攻撃経路を生んでいる
  • ガバナンスの整備が導入ペースに追いついておらず、承認済み開発ツール群をポリシーで強制管理している組織はわずか43%にとどまる
  • AIエコシステムはすでに悪用されており、悪意ある拡張機能・エージェントスキル・モデルが広く使われるレジストリ上で確認されている
  • 脆弱性の件数よりも実際の悪用可能性が重要であり、詳細検証を行った337件の著名なCVEのうち、実環境で高い悪用可能性が確認されたのはわずか12%だった
  • 可視化を実際の行動につなげる必要があり、セキュリティチームは開発ライフサイクル全体にわたって来歴、適用可能性、ポリシー、監査証跡を結び付けなければならない

攻撃対象領域は開発者の後を追ってきた

ツール層だけを見ても、何が起きたかは明らかです。AIネイティブなIDEで利用されるOpenVSXレジストリは、2023年の約1,000件から2025年には3,803件へと拡大し、262%の増加を記録しました。

同じ2025年には、そこで56件の悪意ある拡張機能が検出されており、その中にはVS Code拡張機能を標的とした初の自己増殖型ワーム「GlassWorm」も含まれていました。

GlassWormは目に見えないUnicode文字の中に悪意あるコードを隠し、開発者の認証情報を窃取して自己増殖し、約35,800件のインストールに達しました。

エージェント層の状況も同様に深刻です。JFrog Security Researchは2025年、MCPサーバー全体で20件を超える重大なリモートコード実行の脆弱性を特定しました。その中には、広く使われているmcp-remoteユーティリティにおけるCVSS 9.6の欠陥、CVE-2025-6514も含まれています。

同チームが2026年初めにAIエージェントスキルのレジストリまでスキャン範囲を広げたところ、重大な影響をもたらすペイロードを持つ悪意あるエージェントスキルが969件見つかりました。

モデルの側でも、Hugging Faceのような公開レジストリ上で495件の悪意あるモデルが検出されています。これは、組織の53%がセルフホスティング用にモデルを取得しているのと同じレジストリです。

拡張機能マーケットプレイス、エージェントスキルのレジストリ、モデルハブなど、今や開発者が作業を行うあらゆる場所が、攻撃の配送手段と化しています。

境界線はもはやネットワークの境目ではありません。ソフトウェアを作成し、パッケージ化し、運用するという行為そのものが境界線になっているのです。

ガバナンスのパラドックス

ここでデータは、不都合な現実を突きつけてきます。MCPの利用をどのように統治しているか尋ねたところ、97%の組織が何らかの形の承認済みリストを運用していると回答しました。

一見すると、これは成熟した体制に見えます。しかし、継続的なスキャンを伴わないガバナンスは、単なるリストであって管理体制とは言えません。

より広いツール全体像を見ると、このギャップが裏付けられます。

事前承認済みの開発ツール群を、承認プロセスを経てポリシーで強制的に管理している組織はわずか43%にとどまり、未承認のツールを自動的にブロックする仕組みを導入している組織は39%にすぎません。

その一方で、18%の組織はガバナンスが全く存在しないか、名ばかりのガバナンスしか持っておらず、さらに10%は締め切りに追われる開発者の自主管理に全面的に依存しています。これらを合わせると、実質的に統治されていない組織の割合は全体の4分の1近くに達します。

GlassWormと、深刻度9.6のMCP脆弱性が同じ1年間に発生した脅威環境を踏まえれば、これこそが今日の企業セキュリティにおいて最も明白なギャップだと言えます。

ノイズへの処方箋は精度である

ここで求められているのは、アラートを増やすことではありません。むしろ調査結果は、その逆を示しています。

私たちは、2025年に公開された337件の著名なCVEを対象に、適用可能性を検証するスキャナーを構築しました。単に脆弱なコードが存在するかどうかだけでなく、実際の企業環境において、それを悪用できる条件がそもそも整っているかどうかを検証したのです。

その結果、実際に高い悪用可能性が確認されたCVEは、わずか40件、全体の約12%にとどまりました。

件数ベースのトリアージは、セキュリティチームの役に立ちません。追いかけるべきCVEが増えたからといって、実際のリスクが増えているとは限らないのです。

それが意味するのは、ノイズが増えるということです。そして、本物の脅威はそのノイズの中に隠れています。

CISOにとって、これこそ経営陣に提示すべき論点です。

問うべきは、自社のツールが検出した件数の多さではありません。そのうちどれが自社の環境において本当に重要なのかを立証し、攻撃者に先んじて対処できるかどうかです。

説明責任を伴わない可視化はガバナンスではない

もう一つ、すべてのセキュリティ責任者が立ち止まって考えるべきデータがあります。59%の組織が本番環境における来歴の完全な可視化を実現していると回答した一方で、48%はコンプライアンス監査の証跡を作成するのに1週間以上を要すると答えています。

この二つの数字が、同時に健全なプログラムを反映しているとは考えられません。

可視化が本物であり、構造化され、アクセス可能で、いつでも監査に対応できる状態であれば、証跡の作成には数分しかかからないはずです。数週間もかかるはずがありません。

多くの組織にとって「完全な可視化」とは、データがどこかに存在しているという意味にすぎず、誰もがそれを活用できる状態にあるという意味ではないのです。

だからこそ私は、業界にありがちな反射的な対応、すなわち新たなAI領域が現れるたびに個別のポイントソリューションを継ぎ足していくやり方には懐疑的です。

ここにMCPレジストリ、あそこに拡張機能スキャナー、さらにその先にはモデル検証専門のベンダー、というように。

注目すべきは、38%の組織が今や既存のDevOpsプラットフォームが備えるセキュリティ機能を主軸に据えていると回答している点です。これは、分断されたデータの島々そのものがリスクであるという認識の表れと言えます。

あなたの使命は、そもそも一度に一つの小さな成果物のクラスだけを守ることではなかったはずです。

AI支援によるコードの最初の一行から、本番環境で稼働するエージェントに至るまで、AIアプリケーション全体を守ることこそが本来の使命なのです。

現代のCISOの役目は、ビジネスのスピードを落とすことではなく、そのスピードを保ちながら同時に安全性も確保できるよう後押しすることです。エージェント時代が求めるスピードを実現するために。

そのためには、開発者が構築するあらゆるもの、そしてAIが関わるあらゆるものを横断する、単一の記録システムが必要です。来歴、適用可能性、ポリシーが一箇所に統合された環境です。

そこに真っ先にたどり着いた組織は、単に安全になるだけではありません。同時に、より速くもなるでしょう。なぜなら、実体のないノイズにではなく、本物のリスクにこそ時間を費やせるようになるからです。

翻訳元: https://www.esecurityplanet.com/threats/the-toolchain-is-the-target-securing-software-development-in-the-agentic-era/

本記事は esecurityplanet.com の記事を翻訳・要約したものです。