「シャドーAI」はなぜ既存スキャナーをすり抜けるのか

セキュリティチームにとって、開発者が正式な登録手続きを経ずにデプロイしたAIワークロード(いわゆるシャドーAI)の管理は悩みの種です。組織側は開発速度や安定性を犠牲にしたくないため、特権的なDaemonSet・カーネルレベルのアクセス・手動でのPod仕様編集を開発チームに求めることに及び腰になりがちで、結果として従来型のセキュリティスキャナーはこうしたワークロードを見逃してしまうといいます(出典)。

CISO(最高情報セキュリティ責任者)が求める「完全な可視性」と、SRE(サイト信頼性エンジニア)が求める「クラスタの安定性」——この2つの要求は、これまで両立が難しかった。

特権不要の軽量コントローラーで自動検出

Googleが公開した「k8s-aibom」は、クラスタAPIとコンテナ環境を継続的に監視し、稼働中のAIランタイム(vLLM・Triton等)を自動検出して、業界標準規格「CycloneDX」形式の機械学習部品表(ML-BOM)を生成する軽量なKubernetesコントローラーです。

設計上の最大の特徴は「摩擦ゼロ」であることです。k8s-aibom-systemネームスペースに単一の非特権Deploymentとしてデプロイされ、サイドカー・eBPFカーネルモジュール・特権DaemonSetは一切不要で、既存の開発者のPod仕様を変更する必要もありません。

検出パイプラインは次の4段階で構成されています。

段階 処理内容
クラスタワークロードのスクレイプ KServeリソース・Deployment・StatefulSet・DaemonSet・Jobを継続監視
AIスタックの識別 コンテナイメージ・環境変数・コマンドライン引数からvLLM/Triton/TGI/Ollama等の推論ランタイム、LangChain/AutoGen/CrewAI等のエージェントフレームワーク、Milvus/Qdrant/pgvector等のベクトルDBを検出
標準マニフェストの生成 OWASP CycloneDX 1.6形式のML-BOMドキュメントを作成
出力先への送信 クラスタ内のカスタムリソースに添付するほか、Cloud Storageバケットや外部Webhookにも送信可能

(出典)

重要な性質として、k8s-aibomはクラスタの状態を純粋な関数的入力として扱い、同一のクラスタ入力からは必ずバイト単位で同一のML-BOMドキュメントが生成されるという決定性を備えています。この性質により、GitOpsワークフローとの親和性が高く、SREがAI依存関係のドリフトを正確な差分として検知できるようになります。

「ビルド時スキャン」の限界を「実行時観測」で補う

Googleは、既存の多くのAI BOMソリューションが「ビルド時」に静止状態のアーティファクトからBOMを生成するスキャナーである点を課題として挙げています。これらのツールは「デプロイされるはずだったコード」を追跡するのには役立ちますが、商用のAIセキュリティプラットフォームも含め、ベンダー固有のデータモデルによる外部スキャンが中心で、「今まさに何が動いていて、何に接続されているか」をコンプライアンス担当者やSecOpsチーム、プラットフォームエンジニアが正確に把握できるものは少ないといいます(出典)。

k8s-aibomはこのギャップを埋めるため、アーティファクトのスキャンではなく稼働中のクラスタの実地観測からBOMを生成し、ベンダー固有形式ではなくOWASP・OpenSSFのサプライチェーンエコシステムと親和性の高い標準規格(CycloneDX 1.6 ML-BOM)を採用しています。

自分のGKE環境でもAgent系フレームワークを試すことが増えてきたので、こうした「後から可視化できる」ツールがオープンソースで手に入るのはありがたい話です。特権なしで導入できる点は、個人開発者が気軽に試す上でも障壁が低くて良いと感じます。