AI SECURITY INSIGHTS

AIモデルサプライチェーンセキュリティ、
なぜ今「静的スキャン」だけでは不十分なのか？

組織に入るモデルと外部へ出るAI資産を同時に保護する 双方向セキュリティアーキテクチャ

重要なメッセージ

AIモデルは単なるファイルではありません。
出所と完全性だけでなく、実際の動作やデータ漏えいの可能性まで検証する必要があります。

AIモデルサプライチェーンセキュリティ、なぜ今「静的スキャン」だけでは不十分なのか？

企業におけるAI活用が急速に拡大する中、オープンソースモデルや商用モデル、 Fine-tuned Model、LoRA Adapter、RAG Vector Databaseなど、 さまざまなAI資産が組織の開発・運用環境に導入されています。 AIモデルは今や単なる研究成果ではなく、実際の業務やサービスを構成する 重要なサプライチェーン資産となっています。

しかし、多くのセキュリティ体制は、依然として従来型のソフトウェアサプライチェーンを 基準に設計されています。ファイルハッシュや電子署名の確認、 依存関係やライセンスの検査は不可欠ですが、 それだけでAIモデルの安全性を完全に説明することはできません。

その理由は、AIモデルの内部重み（Model Weights）が、 人が直接確認することの難しい大規模なバイナリ形式で構成されているためです。 外見上は同一または正常に見えるモデルであっても、 実際の実行過程では予期しない動作を示す可能性があります。

AIモデルはソースコードのように確認できない

従来のソフトウェアでは、ソースコードの比較、 静的アプリケーションセキュリティテスト（SAST）、 コードレビューなどを通じて、変更点やリスク要因を追跡できます。 一方、AIモデルの重みは一般的なコードのように差分を比較したり、 人が直接読み取って確認したりすることが困難です。

そのため、以下のようなリスクは静的スキャンだけでは十分に特定できません。

• 隠されたBackdoorや、特定の入力にのみ反応する悪意のある動作
• Poisoned Fine-tuningによって挿入された偏りや意図的な誤動作
• 実際の出所とは異なる表示がされたモデルや供給者情報
• 不正確または許可されていないライセンスおよびProvenance情報
• Agent環境でTool、Memory、Network Accessと結合した際に現れる危険な動作

静的スキャンと動的検証の違い

AIモデルサプライチェーンには二方向のリスクが存在する

AIサプライチェーンセキュリティは、外部から入ってくるモデルを 検査するだけでは完結しません。 組織外から導入されるモデルと、組織内で作成され外部へ提供されるAI資産には、 それぞれ異なるリスクがあり、両方向を管理する必要があります。

1. Inbound Risk：外部モデルが組織内に入る場合

Hugging Faceリポジトリ、外部ベンダー、協力会社、 または商用エンドポイントから導入したモデルには、 実行前の段階からリスクが含まれている可能性があります。 モデルが悪意を持って改ざんされている、 誤った情報が表示されている、 または許可されていないライセンスが使用されている可能性を考慮する必要があります。

• 悪意のあるBackdoorが挿入されたモデル
• データポイズニングまたは改ざんされたFine-tuning成果物
• 出所や供給者を検証することが難しいモデル
• 組織のポリシーに適合しないライセンスを持つモデル

2. Outbound Risk：内部AI資産が組織外へ出る場合

組織が独自に作成したAI資産についても、安全であると断定することはできません。 Fine-tuned Model、LoRA Adapter、RAG Vector Databaseには、 学習や構築に使用された機密情報が残っている可能性があります。

これらの資産が外部へ提供された後、 攻撃者が繰り返し質問や抽出を試みることで、 個人情報、金融情報、医療情報、または社内データを復元した場合、 一度発生した漏えいを元に戻すことは困難です。 そのためOutbound段階では、 「この資産に、作成時に使用された元データを再出力させることが可能か」 を検証する必要があります。

双方向AIモデルサプライチェーンセキュリティ

Model Gate：AIモデルサプライチェーンのための双方向セキュリティゲート

Model Gateは、AIモデルが組織内に入る場合と外部へ出る場合の両方に、 同一のセキュリティ原則を適用する双方向セキュリティアーキテクチャです。 モデルやAI資産は、すぐに運用環境で使用されたり外部へ配布されたりするのではなく、 隔離された状態で検証と承認の手続きを経ます。

Inbound Gateの処理フロー

検査結果は一度限りの判定で終わらない

承認済みのモデルであっても、永続的に安全であるとは見なしません。 Threat Intelligenceまたはポリシーが更新された場合、 影響を受ける承認済みモデルを再びREVIEW_REQUIRED状態へ変更し、 再評価できる必要があります。

また、スキャン結果、ポリシーバージョン、スキャナー識別情報、 Threat Intelligence Snapshot、承認者、例外理由などを、 改ざんが困難な監査ログとして記録することで、 事後検証や規制対応に活用できます。

Dynamic Red TeamingとSafety Card

Model Gateの重要な差別化要素は、 静的スキャンを通過したモデルを、実際のAgent環境に近い条件で 追加検証する点にあります。 隔離されたSandboxで攻撃シナリオを実行し、 モデルの応答とToolの使用動作を分析します。

• Prompt InjectionおよびJailbreakの試行
• 許可されていないTool呼び出しと権限回避の試行
• MemoryまたはContextを利用したポリシー回避
• 機密情報や学習データの抽出試行
• ネットワークおよび外部実行経路の悪用可能性

検証結果は、定量化されたAgentic Safety Cardとして整理できます。 Safety Cardは単なるレポートではなく、 モデルごとのRuntimeポリシーと連携するセキュリティ上の根拠となります。

同一のモデルであっても、安全性レベルや業務目的に応じて、 許可するTool、Network Access、Human Approvalの条件を 個別に設定できます。

Outbound Gate：機密性の高いAI資産を外部へ出す前の検証

Outbound Gateは、Inbound Gateと同一のLifecycle、 Policy Engine、Signed Evidence Bundle、Audit構造を、 外部への持ち出し・配布プロセスに適用します。

Fine-tuned Model、LoRA Adapter、RAG Vector Databaseを外部へ提供する前に、 敵対的なデータ抽出テストを実施します。 繰り返しのプロンプトや迂回的な質問を通じて、 PIIまたは機密データを復元できるかを確認し、 漏えいの可能性が見つかった場合は、 外部提供を遮断するか、追加の確認を要求します。

企業が得られるセキュリティ効果

サプライチェーンリスクの低減

外部モデルの出所、完全性、ライセンス、実際の動作を総合的に検証

データ漏えいの防止

内部で作成されたモデルやRAG資産から機密情報を抽出できる可能性を外部提供前に確認

ポリシーベースの運用

モデルごとのリスクレベルに応じて、承認、隔離、再確認、Runtime制限を適用

監査可能性の確保

検査結果と承認根拠を一貫した証拠体系として記録

継続的な再評価

ポリシーや脅威情報が変更された場合、承認済みモデルも再検証

AIサプライチェーンセキュリティの次の段階

AIモデルサプライチェーンセキュリティは、 もはやモデルファイルを検査するだけでは完結しません。 モデルの出所と完全性を確認することと同様に、 実際の実行環境でどのように動作するのか、 機密情報を漏えいしないか、 組織のポリシーや権限体系を遵守しているかを検証することが重要です。

静的スキャンはAIセキュリティの出発点です。 しかし、AIがAgentとして動作し、 Tool、Memory、Networkと接続される環境では、 動的検証と継続的なポリシー適用を同時に実施する必要があります。

Source basis: “ModelGate: A Bidirectional Security Gate for AI Model Supply Chains — Beyond Static Scanning” (CODE BLUE 2026 CFP Supporting Talk Summary)

ASHはModel Gateを中心に、 AIモデルサプライチェーンの検証からAI Agent Runtime、 Endpointに至るまでを連携するEnd-to-End AI Securityを提供します。