English 
SolarWindsは、企業がソフトウェアのリスクを捉える方法を一変させた。この攻撃は、攻撃者が必ずしも企業に直接侵入する必要はないことを示した。攻撃者は信頼されているサプライヤーを乗っ取り、その関係を利用して内部へ攻撃を仕掛けることができたのだ。ソフトウェアの相互接続性が高まるにつれ、この教訓はますます重要になっている。.
今日、エンタープライズアプリケーションは、オープンソースパッケージ、クラウドサービス、API、機械学習モデル、トレーニングデータ、AIエージェントに依存している場合がある。そのため、ソフトウェアサプライチェーンのセキュリティは、単にソースコードの脆弱性をチェックするだけにとどまらない、はるかに広範な課題となっている。.
2026年に, 65% 売上高に基づく大企業の調査によると、サイバーレジリエンスにおける最大の課題として、サードパーティおよびサプライチェーンの脆弱性が挙げられた。これは2025年の54%から増加したものだ。.
この記事では、そうしたリスクがどこで生じるのか、AIがどのようにそのリスクを拡大させるのか、そして企業がより強固で信頼性の高いソフトウェア・サプライチェーンを構築するために何ができるのかについて考察する。.
重要システムに対する現代の脅威情勢の解明
現代のソフトウェア・サプライチェーン・セキュリティ戦略において、サプライチェーンを開発者からアプリケーションへと続く直線的なものとして捉えてはならない。それは、リポジトリ、依存関係、ビルドシステム、認証情報、外部サービスが絡み合った網の目のような構造である。その複雑さゆえに、攻撃者には侵入を試みるための複数の入り口が存在する。.
ソースコードやリポジトリの乗っ取りは、ソフトウェアサプライチェーンのセキュリティにおいて最も直接的な攻撃経路の一つだ。攻撃者は、GitHubなどの環境において、開発者の認証情報を盗み出したり、アカウントを乗っ取ったり、脆弱なアクセス制御を悪用したりすることができる。一度侵入すると、ソースコードを改ざんしたり、悪意のあるコミットを作成したり、他のシステムへのアクセス権を与える機密情報にアクセスしたりする可能性がある。 Googleは、GitHub Actionsを悪用してリポジトリの機密情報や書き込み権限を取得しようとする攻撃を確認した。これは、開発者向けインフラが、より広範なソフトウェアサプライチェーンへの足掛かりとなり得るという警告である。.
依存関係ポイズニングは、ソフトウェアサプライチェーンのセキュリティにおける新たな問題を引き起こす。 現代のアプリケーションが、開発者が直接選択したライブラリのみに依存していることはめったにない。それらのライブラリによって取り込まれるネストされたパッケージにも依存しているのだ。そのため、悪意のある、あるいは侵害されたコンポーネントは、誰にも気づかれることなく、数層も深く浸透してしまう可能性がある。2026年3月にGoogleが行った、侵害されたAxiosパッケージに関する調査は、そのリスクの規模を如実に示している。そのパッケージには、 100 million 週間のダウンロード数だ。したがって、たった1つの信頼できる依存関係が、非常に広範囲にわたる影響をもたらす可能性がある。.
CI/CDパイプラインの悪用は、事態をさらに深刻なものにする。ビルドシステムは、ソースコード、シークレット、デプロイ設定、そして本番環境のアセットにアクセスできる。もし誰かがJenkinsやGitLab内でより高い権限を取得した場合、ビルドの実行中に悪意のある変更をこっそり混入させる可能性がある。出力は人々が信頼しているのと同じパイプラインから生成されるため、結果は一見正常に見えるかもしれない。 こうして、パイプラインは攻撃者が被害をもたらすために利用できる新たな場所となってしまう。ソフトウェアサプライチェーンのセキュリティは、単にデプロイされるソフトウェアだけでなく、ソフトウェアを作成するプロセスそのものを保護しなければならない。.
サプライチェーンにおけるAIアプリケーションのセキュリティ確保に向けた新たなフロンティア
AIはサプライチェーンを変革する。なぜなら、アプリケーションが依存する要素はもはやコードだけにとどまらないからだ。AIシステムは、基盤モデル、学習データ、モデルの重み、外部API、プラグイン、ツールサーバー、検索システム、エージェントコンポーネントなどを利用する可能性がある。依存関係が一つ増えるごとに、信頼に関する判断がまた一つ加わるのだ。.
モデルポイズニングやデータ改ざんは、その被害が従来のソフトウェアの脆弱性とは異なる形で現れる可能性があるため、特に厄介だ。攻撃者がモデルの学習前に学習データを改ざんしたり、データセットを操作したりすれば、その後のシステムの挙動に影響を与えることができる。この脆弱性は、モデルが本番環境に投入される前にすでに組み込まれているのだ。そのため、データの出所追跡やモデルの系譜は、ソースコードの出所追跡と同様に重要となる。.
サードパーティ製のAI依存関係は、さらなる複雑さを加える。開発者は、Hugging Faceなどの公開リポジトリから、事前学習済みのモデルやサポートコンポーネントをダウンロードすることがある。これにより開発を加速できるが、そのスピードの裏には危険な前提が隠れている可能性がある。正しく動作するコンポーネントが、必ずしも信頼できるコンポーネントであるとは限らない。 企業は、モデルの出所、その内容、そしてその完全性が暗号技術によって立証できるかどうかを検証する必要がある。.
AIエージェントが再び境界を広げた。マイクロソフトによる2026年のAIエージェントに関する研究では、, external components また、サプライチェーンのリスクを考慮すると、エージェントが利用するツール、依存関係、および外部コンポーネントを、ソフトウェア・サプライチェーンの一部として扱うことが重要となる。これは、エージェントが従来のアプリケーションよりもはるかに自律的に、システムとやり取りしたり、ツールを呼び出したり、外部サービスを利用したりできるためである。.
シャドウAIは、技術的な問題に加え、ガバナンス上の問題も引き起こす。 開発者は、問題をより迅速に解決できるという理由で、承認されていないAI APIやツールを使用することがある。しかし、独自開発のコード、内部文書、あるいは機密データが、セキュリティチームの知らぬ間に企業の境界を越えて流出する可能性がある。したがって、問題は単に組織がどのAIモデルを使用するかということではない。開発環境に接続されているすべてのAI依存関係を、組織が把握し、制御できるかどうかが問題なのだ。.
緩和策と企業のベストプラクティスの青写真
優れたソフトウェア・サプライチェーン セキュリティ それは、単一のスキャナーや単一のポリシーから生まれるものではない。強力なプログラムとは、開発のあらゆる段階において信頼を測定可能にするものだ。それは、侵害を困難にし、権限を制限し、環境に何が入ってきたかの証拠を提供する、多層的な制御を構築することから生まれる。.
SBOMおよびAI-BOMの導入を義務付ける
何よりもまず可視性が重要だ。企業は、存在すら把握していない依存関係を保護することはできない。ソフトウェア部品表（SBOM）は、直接および間接的な依存関係を含め、アプリケーション内のコンポーネントの一覧をセキュリティチームに提供する。この一覧は、脆弱性の追跡やサプライヤーの審査を支援し、コンポーネントが侵害された際の迅速な対応を可能にする。.
この考え方は、 AI. AI-BOMは、AIアプリケーションに影響を与えるモデル、データセット、フレームワーク、API、プラグイン、その他のコンポーネントに関する可視性を提供すべきだ。その目的は、誰も読まないような文書をもう一つ作成することではない。目的は、システムの信頼関係を示す実用的なマップを作成することだ。.
パッケージの一覧は、セキュリティチームに何が存在しているかを示す。有用なサプライチェーンのインベントリは、各コンポーネントの出所、保守担当者、使用場所についても明らかにする。こうした背景情報があることで、対応が迅速化される。.
SLSA を用いてビルド環境を強化する
ソフトウェアのサプライチェーンセキュリティとは、本番環境と同様にビルド環境も慎重に保護することを意味する。SLSA（Supply-chain Levels for Software Artifacts）は、ソフトウェアの完全性と出所を追跡するためのフレームワークを提供する。企業は、アーティファクトがどこから来たのか、どのように生成されたのかを特定できる必要がある。.
Googleの2026年版脆弱性管理ガイドラインでは、次のように推奨している SLSA, 、孤立した一時的なCI/CDランナー、一元化された依存関係リポジトリ、およびプロヴェナンス管理。こうした取り組みにより、永続性が低減され、影響範囲が限定される。.
一時的なビルドは、永続性を低減するため特に有用だ。ビルド用にクリーンな環境が作成され、その後破棄される。コード署名は、下流のシステムがアーティファクトが承認されたソースおよびプロセスから生成されたものかどうかを確認できるようにすることで、さらなる検証層を追加する。これらを組み合わせることで、改ざんされたリリースの発生を困難にする。.
CI/CDにおけるゼロトラストと最小権限の導入
CI/CDの認証情報は、本番環境レベルの機密情報として扱うべきだ。開発者のマシンやスクリプト、共有環境に無期限に放置してはならない。AWSは次のように推奨している temporary credentials, 、最小権限の原則、認証情報の自動ローテーション、一元化された依存関係管理、アーティファクトの署名、および継続的なスキャンを、ソフトウェアサプライチェーン保護の各層として。.
最小権限の原則は、ソフトウェア・サプライチェーンのセキュリティにおいて特に重要だ。開発者やビルドプロセスは、その特定のタスクに必要なアクセス権のみを持つべきである。あるアカウントが侵害されたとしても、攻撃者がリポジトリ、クラウドリソース、デプロイメントシステムを横断する経路を自動的に得てはならない。.
開発者アカウントにおいても、IDは依然として一般的な侵入経路であるため、MFAは重要だ。しかし、MFAだけでは不十分だ。企業には、短命な認証情報、アクセス範囲の制限、秘密鍵のローテーション、そして開発、ビルド、本番の各パイプラインにおけるより徹底した分離が必要だ。ゼロトラストに基づいてパイプラインを実装する場合、あらゆるものが侵害される可能性があるという前提が置かれる。.
DevSecOpsにおける継続的なセキュリティ自動化
セキュリティチェックは、ソフトウェアのデプロイ後ではなく、開発中に実施すべきだ。ソフトウェア構成分析（SCA）により、脆弱性やリスクのある依存関係を特定できる。静的アプリケーションセキュリティテスト（SAST）では、ソースコードを検査して弱点を見つけ出すことができる。動的アプリケーションセキュリティテスト（PAT）では、実行中のアプリケーションをテストし、悪用可能な挙動がないかを確認できる。.
これらのツールは、自動化されたポリシーゲートと連携させることで、さらに有用になる。重大な依存関係の問題が発生した際、単にダッシュボードに新たなアラートが表示されるだけでは不十分だ。リスクが定義された閾値を超えた場合、パイプラインはリリースを停止したり、是正措置を要求したり、セキュリティ承認を求めたりできるべきだ。.
継続的なスキャンは、初期のビルド段階にとどまらず、その先にも及ぶ必要がある。AWSは、多層的なサプライチェーン保護の一環として、継続的なスキャンを推奨している。コンポーネントは、後から侵害される可能性もある。ソフトウェア サプライチェーン したがって、セキュリティ対策は、依存関係の選定やコードのコミットから、ビルド、デプロイ、実行時の監視に至るまで、ライフサイクル全体を通じて実施されなければならない。.
こちらもお読みください： サカナAI、SCSK、住友商事がAIアライアンスを結成した
サプライチェーンのレジリエンスの未来
ソフトウェア・サプライチェーンのセキュリティにおける次の段階では、ニュースになった脆弱性への対応というよりも、パイプラインに何が流入するのかを絶えず問い直すことが重要になるだろう。. IBM によると、過去5年間で、主要なサプライチェーンやサードパーティにおけるセキュリティ侵害が4倍に増加したという。そのため、事後対応的なパッチ適用だけではますます不十分になっている。.
AIは、攻撃者が発見プロセスを自動化できる一方で、企業もAIを活用して膨大なソフトウェア環境全体で不審な挙動を検知できるため、さらなる複雑さを加えることになる。成功する戦略は、盲目的な自動化ではない。継続的な検証、明確な出所追跡、アクセス制御、そして何かが変化したことを把握できる十分な可視性こそが鍵となる。 自社のパイプラインを重要インフラとして扱う企業は、ソフトウェア・サプライチェーンのセキュリティを強化し、次回のサプライチェーン侵害に耐えうる態勢を整えることができるだろう。.
日本語