Author Archives: DeveloperTiatra

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）とG7のサイバー機関パートナーが、AI SBOM（AIソフトウェア部品表）の最低限の要素リストを公表した。企業環境に導入されるAIシステムのセキュリティと出所をCISOが評価するための手がかりとなる。

このガイダンスは従来のSBOM（ソフトウェア部品表）の概念をAIに拡張するもので、モデル、データセット、ソフトウェアコンポーネント、プロバイダー、ライセンス、その他の依存関係の文書化を求めている。CISAによれば、これらの最低限の要素は網羅的でも強制的でもないが、G7の専門家間のコンセンサスを反映しており、AIテクノロジーの進化に伴って拡張される見込みだ。

セキュリティリーダーにとって、このガイダンスはAIリスクをサプライチェーン管理の枠組みに位置づけるものだ。ソフトウェアの構成管理、クラウドサービス、サードパーティのテクノロジープラットフォームに関するベンダーリスクの議論と同じ文脈で、AI SBOMも扱われるようになる可能性がある。ただし一つ大きな違いがある。AIリスクはモデル、データ、インフラ、システムの振る舞いによって形成されるため、AI SBOMはソフトウェアの構成を超えた可視性が必要だ。

「AIシステムは、従来のソフトウェアにはなかった不透明さをもたらす」とIDCアジア太平洋サイバーセキュリティサービスのシニアリサーチマネージャー、Sakshi Grover氏。「モデルの系譜、学習・推論データ、ファインチューニングの履歴、プロンプト、ベクターデータベース、サードパーティの基盤モデル、API、オーケストレーションロジック、実行時の振る舞いなどだ」と続ける。

ConfidisのCEO、Keith Prabhu氏はAIソフトウェアの本質的な違いをこう説明する。「AIソフトウェアはソフトウェアコンポーネントを超えたものを内包する。モデル、学習データ、プロンプトとシステム指示、モデルの重みとチェックポイント、GPUの依存関係も追跡する必要がある」。

Greyhound ResearchのチーフアナリストSanchit Vir Gogia氏はより広く捉える。「問いはもはや『この製品にはどんなコードが入っているか』ではない。『どんなコード、モデル、データ、インフラ、制御、ベンダーの決定がこのシステムの振る舞いを形成しているか』だ」。

実際にどう活用するか

このガイダンスの当面の活用先は調達とベンダーリスク管理だ。AIを組み込んだ製品を本番環境に入れる前に、セキュリティチームがベンダーに透明性を求める根拠になる。「組織はベンダーに対して、モデルの出所、学習データのソース、ソフトウェアとAPIの依存関係、ライセンスの義務、セキュリティテストの実践、更新サイクル、実行時の監視制御、責任の分担範囲について情報開示を求めるべきだ」とGrover氏は言う。

精査の程度はサプライヤーの種類によっても変わる。「大手ベンダーには、サードパーティの基盤モデルへの依存関係、地理的なデータフロー、モデルの更新方針、顧客データがモデルの学習やファインチューニングに使われているかどうかの透明性を求めるべきだ。スタートアップには、ガバナンスプロセスの成熟度、依存関係の追跡、セキュアな開発プラクティス、IDの管理、AIライフサイクル全体の運用監視に焦点を当てるべきだ」とGrover氏は言う。リスクの高い用途では、AI SBOMはデータフロー、セキュリティアーキテクチャ、モデルの振る舞い、プライバシー影響、レッドチームの調査結果、インシデント対応、ログ、プロンプトインジェクションテストに関する文書を含む広範なベンダーエビデンスの一部となるべきだとGogia氏は言う。

課題は残る

最大の課題は、AI SBOMはベンダーが「何があると言っているか」を示すに過ぎない点だ。つまり、そのシステムが実際に信頼できるかどうかを証明するものではない。「最低限の要素が生むのは可視性であって、保証ではない」とGogia氏は言う。

難しいのは、その文書が現実と一致することを証明することだ。セキュリティチームはベンダーからAI SBOMを受け取っても、それが本番環境で実際に動いているシステムを反映しているかどうか、またAI環境の変化に追いついているかどうかを判断する必要がある。

Prabhu氏は、品質の高いAI SBOMでもAIリスクへの可視性は部分的なものに過ぎないと言う。AIの振る舞いの変化、ハルシネーション、プロンプト利用の変化、学習データの透明性の限界が、実際のリスク評価を難しくし続ける。AIシステムが成熟するにつれ、AI SBOMもそうしたギャップに対応するよう進化しなければならないとPrabhu氏は指摘する。