BadBoneとAIサプライチェーン：モデル自体がリスクとなる時
過去3年間、エンタープライズセキュリティにおけるAIの議論は、AIエージェントが稼働した後にデータで何をするかにほぼ集中してきました。BadBoneは、その議論の焦点をより上流、つまりモデル自体が環境に到達する前に侵害された場合に何が起こるかに移します。
BadBoneの中核的なイノベーションは、「休止状態」と「アクティブ状態」の分離にあります。従来のAIバックドア攻撃は、特定の入力パターンが与えられたときに即座に発動するトリガーを仕込みますが、これは異常な出力挙動を検知する防御策に見つかりやすいものでした。BadBoneは2段階のアクティベーションでこれを回避します。第一段階はファインチューニングです。組織がモデルをダウンロードしてプロンプト学習を適用すると、休止中のバックドアが起動します。このとき重みが攻撃者の意図通りに変化しバックドアが解放されますが、この変化は外部からは通常のファインチューニングにしか見えません。第二段階はトリガー入力です。ファインチューニング後、特定の入力がバックドアを発動させ、攻撃者が意図した出力を生み出します。
防御のギャップは構造的なものです。防御策はファインチューニング前のベースモデルをスキャンしますが、バックドアはファインチューニング後にアクティブになります。防御が注視しているタイミングと、バックドアが有効になるタイミングが一致しないのです。これは、SolarWindsサプライチェーン攻撃が効果的だった理由と同じで、悪意のある改変が標準的なセキュリティ検証の範囲外で導入されたためです。
5つの重要なポイント
1. BadBoneはスキャン時ではなく、ファインチューニング時にバックドアを発動させる。
2026年6月2日に公開された査読付き論文は、2段階の攻撃を実証しました。バックドアはベースモデル内で休止状態にあり、被害組織がプロンプト学習やカスタマイズを行うと発動します。ファインチューニングという日常的な技術作業が、セキュリティイベントとなるのです。公開された6つの防御策はいずれも、ほとんどの構成でこれを検知できませんでした。なぜなら、ファインチューニング前のベースモデルしかスキャンしないからです。脅威はスキャンウィンドウが閉じた後に初めてアクティブになります。
2. 6つの標準的な防御策が失敗した。
Neural Cleanse、ABS、MNTD、NAD、CLP、D-BRは、現在のバックドアモデル検知の標準的な手法です。しかし、BadBoneはいずれにも確実に検知されませんでした。これは単一ツールの失敗ではなく、防御カテゴリ全体が攻撃に敗北する前提で構築されていたことを示しています。トリガーが発動すると、BadBoneは標的入力の99%を誤分類させつつ、それ以外の入力では通常通りの精度を維持するため、行動監視による検知はほぼ不可能です。
3. AIモデルの重みは、十分に検証されていない攻撃対象領域であり、適切なスキャンツールが存在しない。
SBOM、コード署名、静的解析はAIモデルファイルには適用できません。ダウンロードしたファイルのハッシュは検証できますが、重みにエンコードされた挙動を監査することはできません。ファウンデーションモデル市場は、少数のプロバイダーが重みをリポジトリ経由で配布し、何百万もの組織がそれをダウンロード・カスタマイズするという構造を持っており、これは高インパクトなサプライチェーン攻撃対象領域の特徴です。信頼されたチャネルで配布された1つの重みファイルが、数千の組織に到達する可能性があります。
4. モデルの完全性に依存しない防御策は、コンテンツ層のガバナンスである。
侵害されたモデルがアクセスできるデータが、モデル自身の判断ではなく独立したポリシーによって管理されていれば、バックドアモデルの被害範囲はガバナンス層が許可する範囲に限定されます。この原則はゼロトラストと同じです。モデルの自己判断を信用せず、すべてのデータリクエストをモデルが参照・変更できないポリシーで評価します。
5. 規制環境では、管理されていないAIモデルアクセスが直接的なコンプライアンスリスクとなる。
CMMC 2.0 レベル2は、人間かAIエージェントかを問わず、CUIへのすべてのアクセスに対してアクセス制御と監査ログの強制を求めています。独立したアクセス制御なしでCUIにアクセスするバックドアモデルは、CMMC違反となります。HIPAAやEU AI法も、PHIや高リスクAIシステムデータへのアクセスに同様のロジックを適用します。
あなたの組織のセキュリティ、信じていますか？本当に証明できますか？
Read Now
AIモデルの重み：見過ごされてきた攻撃対象領域
CrowdStrike 2026年グローバル脅威レポートでは、AIを活用した攻撃者活動が前年比89%増加したことが記録されています。BadBoneはこの状況に新たなベクトルを加えます。攻撃者がAIを使って組織を攻撃するのではなく、AIモデルのアーティファクト自体が、導入する組織への攻撃の配布手段となるのです。
ソフトウェアサプライチェーンセキュリティのツール群（SBOM、証明書による証明、コード署名、ソフトウェア構成解析）はAIモデルファイルには適用できません。モデルの重みファイルはバイナリアーティファクトであり、既存のサプライチェーンセキュリティツールでは実質的な監査ができません。ダウンロードしたファイルのハッシュは検証できますが、重みにエンコードされた挙動の完全性は検証できません。
Ciscoプライバシーベンチマーク調査によると、従業員の45%が職場でAIツールを利用しています。バックドアモデルが顧客向け分類ワークフローや社内ドキュメント処理パイプラインに組み込まれると、利用拡大に比例して攻撃対象領域が広がりますが、多くの組織には異常を検知する仕組みがありません。
なぜモデルレベルの防御だけでは不十分なのか
BadBoneの研究は、6つの防御策を破ったこと自体を主張しているのではありません。モデル層だけで構築された防御策には本質的な限界があること、つまり「導入前に安全ならカスタマイズ後も安全」という前提が信頼できないことを示しています。
モデルレベルの防御策は、ファインチューニングを必要としない単純な攻撃には有効な保護を提供します。しかし、AIサプライチェーンリスクへの主な防御策として扱うことは、BadBoneが示すように不完全な脅威モデルに依存しています。エンタープライズセキュリティチームにとって実務上の課題は、ファインチューニング後の重みをモデルレベルで検査する手法がまだ成熟していないことです。OWASP Agent Memory GuardプロジェクトはMLベースの異常検知機能の追加を発表していますが、これらはまだ本番運用には至っていません。当面のより堅牢な防御策は、モデルがアクセスすべきデータをモデル自身の判断に委ねないことです。
コンテンツ層ガバナンスによる対応
コンテンツ層でのAIデータガバナンスは、モデルの完全性に依存しない防御を提供します。モデルが安全かどうかではなく、モデルがアクセスできるデータが、モデルが上書きできないポリシーで管理されているかどうかが問われます。どのモデルが稼働しているか、またそのモデルが侵害されているかどうかに関係なく、すべてのAIエージェントによる機密コンテンツリポジトリへのアクセスは、独立したポリシーエンジンによる属性ベースアクセス制御で仲介されます。モデルがファイル取得、データベースクエリ、データ送信をリクエストする際、そのリクエストはモデル内には存在しないポリシーで評価されます。
Kiteworks Secure MCP ServerとAI Data Gatewayは、このアーキテクチャを実装しています。機密コンテンツにアクセスするすべてのAIエージェントは認証され、リクエスト単位でABACポリシーに基づいてアクセスが評価され、すべてのやり取りは改ざん検知可能な監査ログに記録されます。バックドアモデルが外部エンドポイントにデータを流出させようとしても、ポリシーエンジンはモデルの意図を知ることも気にすることもなく、アクセスリクエストをガバナンスポリシーで評価し、許可されていないものはブロックします。Kiteworksプライベートデータネットワークは、このアーキテクチャをメール、ファイル共有、MFT、SFTP、Webフォーム、APIにまで拡張し、1つのポリシーエンジンと統合された監査ログで管理します。
CMMCやFedRAMP環境では、コンテンツ層の防御は必須です。CMMC 2.0 レベル2は、人間かAIエージェントかを問わず、CUIへのすべてのアクセスに対してアクセス制御と監査ログの強制を求めています。独立したアクセス制御なしでCUIにアクセスするバックドアモデルは、CMMC違反となります。
今、組織が取るべきこと
BadBoneは学術的な概念実証であり、実際の攻撃として確認されているわけではありません。しかし、ソフトウェアサプライチェーンセキュリティにおける概念実証は、公開から12〜24か月以内に実運用技術となるのが通例です。
まず、すべてのAIエージェントやモデル導入時のデータアクセス範囲を見直してください。問うべきはモデルの信頼性ではなく、モデルのデータアクセスがガバナンス層によって制限され、たとえモデルの挙動が侵害されても異常なアクセスパターンを検知できるかどうかです。
次に、AIモデルのファインチューニングをセキュリティイベントとして扱ってください。ファインチューニングのワークフローで、ベースモデルの重みをセキュリティレビューなしに公開リポジトリからダウンロードしている場合、BadBoneが示した脆弱性をそのまま抱えていることになります。
三つ目に、AIエージェントの認証情報やAPIトークンは個別に範囲を限定し、定期的にローテーションし、ゼロトラスト原則で管理してください。侵害されたモデルが割り当てられた権限を超えられなければ、その被害も限定的になります。
四つ目に、コンテンツ層のガバナンスを実装し、モデルの内部完全性に関係なく、ポリシーで管理されたデータ環境内でのみ動作させてください。BadBoneへの防御となるAIガバナンス管理（エージェントアクセスの範囲限定、独立したポリシー強制、改ざん検知可能な監査ログ）は、CMMC 2.0、HIPAA、EU AI法でもすでに求められているものです。今これらを構築することで、コンプライアンス義務とAIサプライチェーンリスクの両方に対応できます。
AIサプライチェーンから機密データを守る方法について詳しく知りたい方は、カスタムデモを今すぐご予約ください。
よくある質問
BadBoneは、ファウンデーションモデルに休止状態のバックドアを仕込み、被害組織がプロンプト学習でファインチューニングしたときのみ発動します（導入前の検査時には発動しません）。従来の攻撃は、ベースモデルにトリガーを埋め込み、防御策がスキャンできるものでした。BadBoneの2段階アクティベーションは、ファインチューニング前にスキャンする防御策を回避します。脅威はスキャンウィンドウが閉じた後に初めてアクティブになるためです。トリガーが発動すると、クリーンな入力で精度低下が検知されることなく、標的入力の99%を誤分類させます。
Neural Cleanse、ABS、MNTD、NAD、CLP、D-BRは、ベースモデルの異常な出力挙動をスキャンしてバックドアを検知します。BadBoneはスキャン時にバックドアを休止状態に保つため、ベースモデルは通常通りに動作します。バックドアはファインチューニング後に発動し、防御策がモデルをクリアした後に発生します。これは構造的な限界であり、ファインチューニング前のベースモデルをスキャンする防御策では、ファインチューニング時に発動する攻撃を検知できません。OWASP Agent Memory Guardプロジェクトは、このギャップに対応するためMLベースの異常検知機能を計画していますが、まだ本番運用には至っていません。
コンテンツ層ガバナンスは、データアクセスの判断をモデル自身に委ねず、すべてのAIエージェントによる機密コンテンツへのアクセスや送信リクエストを、モデルが影響できない独立したABACポリシーエンジンで評価します。Kiteworks Secure MCP ServerとAI Data Gatewayはこれを実装しており、バックドアモデルがデータ流出を試みても、ポリシーで許可されていないものは記録付きでブロックされます（モデルの意図に関係なく）。
BadBoneは学術的な概念実証であり、実際に使われている攻撃として確認されているわけではありません。その意義は、これまで理論上だった攻撃手法の実現可能性を示したことにあります。ソフトウェアセキュリティの歴史的パターンとして、新しい攻撃ベクトルに関する概念実証研究は12〜24か月以内に実運用化される傾向があります。BadBoneへの防御策（AIエージェントアクセスの範囲限定、独立したポリシー強制、改ざん検知可能な監査ログ）は、CMMC 2.0、HIPAA、EU AI法でもすでに求められているものです。今これらを構築することで、コンプライアンス義務と将来のAIサプライチェーンリスクの両方に対応できます。
従来のサプライチェーンセキュリティツールは、監査可能なコードやバイナリ向けに設計されてきました。AIモデルの重みは数十億の浮動小数点値で構成され、その挙動は全体の組み合わせから生じるため、個別の要素を検査しても意味がありません。ファイルの暗号学的ハッシュは検証できますが、休止状態のバックドアが重みに埋め込まれているかどうかは監査できません。補完的なコントロールとしては、コンテンツ層でのゼロトラストデータ保護が挙げられます。モデルの内部完全性に関係なく、ポリシーで管理されたデータ環境内でのみ動作させ、すべてのやり取りを証拠品質の監査証跡として残すことが重要です。
追加リソース
- ブログ記事
ゼロトラスト戦略で実現する手頃なAIプライバシー保護 - ブログ記事
77%の組織がAIデータセキュリティで失敗している理由 - eBook
AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレットをしている理由 - ブログ記事
あなたのデータに「–dangerously-skip-permissions」は存在しない - ブログ記事
規制当局は「AIポリシーがあるか」ではなく、「その有効性の証拠」を求めている