JFrog（ジェイフロッグ）は、同社のAIカタログがNVIDIA NIMモデルを、コンテナイメージやパッケージの依存関係に既に適用されているサプライチェーンガバナンスの下に置くようになったと発表した。これは、組織的な管理を経ずにNVIDIAのNGCレジストリから直接、本番環境に対応したAIモデルを取得できてしまうという現状を打破することを目的としている。同社は、4社のうち3社が1年以内にエージェント型AIを導入する計画であり、導入のスピードがガバナンスの整備を上回ることが多いため、多くの開発チームやコーディングエージェントが既に確立されたサプライチェーン外でNIMモデルを利用している現状を指摘した。
JFrogは、NIMモデルが内部統制を回避すると、スキャンもバージョン管理も監査もされていない状態で環境に導入され、以前Dockerイメージ、npmパッケージ、Maven依存関係で対処されたリスク状況が再び発生すると警告した。NGCからの直接プルでは重要なチェックがスキップされる。組織固有のキュレーションポリシーの評価が行われず、Artifactoryはモデルのバージョンを記録せず、セキュリティーチームは過去のビルドでどのAIモデルが実行されたかを記録する監査証跡を失うことになる。
JFrogによると、AIカタログではNVIDIA NIMモデルはネイティブのファーストクラスのアーティファクトとして扱われ、他のバイナリーと同様に管理、バージョン管理、およびセキュリティーが確保される。NIMモデルはArtifactoryを経由してルーティングされ、既存のロールベースのアクセス制御の下に置かれ、JFrog Curationポリシーによって評価される。これは、別のレジストリーや並行ガバナンスプロセスに存在するものではない。同社は、統合された検出機能を重要な機能として挙げており、開発者やエージェントがモデルを取得する前に、メタデータ、バージョン履歴、ガバナンスステータスを表示する単一のカタログビューにNIMモデルとHugging Faceモデルが一緒に表示されると説明している。
JFrogは、カタログ内の全てのNIMモデルには明確なガバナンスステータスが付与されており、セキュリティーチームやプラットフォームチームは、ライセンス、コンプライアンス、および内部リスクポリシーに基づいて、モデルを許可またはブロックできると説明している。同社は、導入前後の効果を比較し、以前はモデルがチェックされずに開発環境や本番環境に到達していたが、AIカタログでは、開発者に到達する前に許可リストと照合されるかブロックされる、以前は明確な回答が得られなかった監査要求も、Artifactoryのレコードで解決できるようになった、夜間にモデルを取得する自動エージェントも、他のアーティファクトと同様に依存関係制御の対象となる。
製品の導入プロセスはシンプルだ。認証は、生成されたDockerログインコマンドによって行われ、NIMクライアントをArtifactory経由でNGCに接続する。検出は、ガバナンスステータスが確認できる統合カタログで行われ、デプロイは、生成されたDockerコマンドを使って、NIMモデルをローカルまたはKubernetes上でArtifactory経由でプルして実行する。JFrogは、このフローにより、開発者とコーディングエージェントは、ガバナンスがバックグラウンドで透過的に実行される間、数分で検出からモデルの実行に移行できることを強調した。
JFrogはまた、AIカタログが複数のパブリックAIハブを網羅し、NVIDIA NIMをHugging Faceモデルと並んでArtifactory内の単一の管理レジストリーに配置できるようになったことも明らかにした。このアプローチにより、AIアセットはDockerイメージ、パッケージ、バイナリーとともに、単一のロールベースのアクセス制御モデル、単一の監査証跡、そしてJFrog XrayおよびCurationによって提供される同一のポリシー適用のもとで管理される。
出典：JFrog
この製品の詳細については、JFrog製品ページをご覧ください。
