私のキャリアの大半において、ソフトウェアサプライチェーンのセキュリティとは、開発者が取り込むもの、つまり依存関係やベースイメージ、サードパーティーパッケージを精査することを意味していた。
しかし、今やその捉え方は危険なほど不完全だ。
この1年で、攻撃者は上流へと移動し、パッケージを通り越して、開発者がそもそもコードを書くために使うツールにまで手を伸ばしている。
IDE拡張機能、AIコーディングアシスタント、Model Context Protocol（MCP）サーバーは、今や開発者インフラの標準だ。
これらはコードベースや認証情報、CI/CDパイプラインへのアクセス権を持つ。しかも、ほとんどのセキュリティフレームワークは、そもそもこれらを可視化するようには作られていない。
これは仮説ではなく、構造的な変化だ。JFrogの2026年ソフトウェアサプライチェーンセキュリティ動向レポートによると、現在41%の組織がAIおよびMLライブラリを積極的に利用しており、1年前の34%から増加した。また、平均的な組織が管理するこれらのパッケージ数は、昨年より47%増えている。
AIは単にサプライチェーンというカテゴリーを追加しただけではない。サプライチェーンそのものが、ますますAIになっている。
重要なポイント
- 開発者向けツールは今やソフトウェアサプライチェーンの一部であり、IDE拡張機能、MCPサーバー、AIモデル、エージェントスキルが新たな攻撃経路を生み出している。
- ガバナンスは導入に追いついておらず、承認済みの開発者ツールをポリシーで強制管理している組織はわずか43%にとどまる。
- AIエコシステムはすでに兵器化されており、広く利用される各種レジストリで、悪意ある拡張機能やエージェントスキル、モデルが見つかっている。
- 脆弱性の件数よりも悪用可能性が重要だ。注目度の高い337件のCVEを検証した結果、実環境で高度に悪用可能だと判明したのは12%にすぎなかった。
- 可視化は行動につながらなければならない。そのためには、セキュリティチームが開発ライフサイクル全体で、出所、適用可能性、ポリシー、監査証跡を結び付ける必要がある。
攻撃対象領域は開発者に追随した
ツール層だけを見ても、何が起きたかは明らかだ。AIネイティブIDEが利用するOpenVSXレジストリは、2023年の約1,000個から2025年には3,803個へと増加し、262%拡大した。
同じ年、そこでは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近くに達する。
わずか1年の間にGlassWormと深刻度9.6のMCP脆弱性を生み出した脅威環境を前にすれば、これは今日のエンタープライズセキュリティにおける最も明白なギャップだ。
ノイズへの解毒剤は精度だ
いずれも、アラートを増やすべきだという話ではない。調査が示しているのはむしろ逆だ。
2025年に公開された注目度の高い337件のCVEについて、適用可能性スキャナーを構築した。脆弱なコードが存在するかどうかだけでなく、実際のエンタープライズ環境に悪用条件が存在するかどうかも検証した。
そのうち、実際に高度な悪用が可能だと判明したのは40件、約12%にすぎなかった。
件数ベースのトリアージはセキュリティチームを追い詰めている。追跡すべきCVEが増えても、実際のリスクが増えるとは限らない。
増えるのはノイズであり、現実の脅威が隠れるのはそのノイズの中だ。
CISOにとって、これは取締役会に示すべき論拠だ。
問題は、ツールがいくつの検出結果を生成するかではない。自社の環境でどれが重要なのかを証明し、攻撃者より先に対処できるかどうかだ。
説明責任のない可視化はガバナンスではない
もう1つ、すべてのセキュリティ責任者が注目すべきデータがある。組織の59%が本番環境の出所情報を完全に可視化できていると回答する一方、48%はコンプライアンス監査の証跡を作成するのに今も1週間以上かかっている。
この2つの数字が、健全なプログラムを同時に示しているはずはない。
可視化が本物、つまり構造化され、アクセス可能で、監査に対応できるものなら、証跡の作成にかかるのは数週間ではなく数分のはずだ。
多くの組織にとって「完全な可視化」とは、データがどこかに存在するという意味であって、誰かがそれに基づいて行動できるという意味ではない。
だから私は、新たなAIの攻撃対象領域が現れるたびに新しいポイントソリューションを追加する、業界の反射的な対応に懐疑的なのだ。
ここにはMCPレジストリ、あそこには拡張機能スキャナー、その次にはモデル審査ベンダー、といった具合だ。
注目すべきことに、現在38%の組織が既存のDevOpsプラットフォームのセキュリティ機能に主に依存していると回答している。これは、断片化されたデータの孤島自体がリスクだという認識を示している。
あなたの使命は、個々の小さなアーティファクトクラスを一つずつ安全にすることではなかった。
最初のAI支援コードの1行から、本番環境で稼働するエージェントまで、AIアプリケーション全体を安全にすることだ。
現代のCISOの役割は、事業部門が迅速に動きながら同時に安全でいられるよう支援することだ。つまり、エージェント時代が求めるスピードを実現し、遅らせないことである。
そのためには、開発者が構築するものすべてとAIが触れるものすべてを横断する単一の記録システムが必要になる。出所、適用可能性、ポリシーが一体となって存在する場所だ。
そこにいち早く到達した組織は、安全になるだけではない。より速くもなる。存在しないノイズではなく、現実のリスクに時間を使えるからだ。