Rubrik Code GuardianがProject Hourglassを拡張、ただしセキュリティ主張は実環境での検証を迫られる
Rubrikは10月9日、Rubrik Code Guardianを発表し、Project Hourglassの対象をランタイム制御から拡張して、コードリポジトリ内の悪用可能な攻撃チェーンを検査できるようにした。同社によると、このプライベートプレビューのサービスは、隔離されたテスト環境内でAnthropicのモデルを使用する。これはソフトウェア開発で拡大する対立を狙ったものだ。AIコーディングツールは成果物を増やす一方、セキュリティチームは同じ速度でそれらをレビューすることに苦戦している。
この拡張により、Rubrikはアプリケーションセキュリティ市場にさらに近づく。この市場では、既にスキャナーがデプロイ前の脆弱なコードを検出している。Rubrikが掲げるのは異なる約束だ。Code Guardianは、考えられる欠陥を列挙するだけでなく、ファイル、サービス、ID、クラウド境界にまたがる弱点を結び付けるよう設計されている。そのうえで、重大なビジネス被害につながり得る経路を優先順位付けする。
ただし、このアプローチはProject Hourglassにとって中心的な検証課題も生む。AIシステムは大規模なリポジトリ全体を横断して推論できるかもしれないが、企業には依然として、その検出結果が正確で、再現可能であり、レビュー対象のコードより安全であることの証拠が必要だ。Code Guardianは一般提供されておらず、Rubrikも機能と性能は変更される可能性があると明示している。
Rubrik Code GuardianがProject Hourglassをコードベースへ拡張
Project Hourglassは、実行時のコーディングエージェント制御から、エージェントが生み出すソフトウェアの検査へと拡張している。
Rubrikは当初、グローバルシステムインテグレーターがAnthropicのClaude Codeを中心にRubrik Agent Cloudを展開できるようにするため、Project Hourglassを立ち上げた。初期アーキテクチャは、AIコーディングエージェントが動作中に何を行うかに焦点を当てていた。
その制御には、行動ガードレール、プロンプトコンテキストの保護、Agent Rewindが含まれていた。RubrikはAgent Rewindを、エージェントによる意図しない操作を元に戻す手段として説明している。これらの機能は、ソフトウェアエージェントにファイルの読み取り、リポジトリの変更、ツールの呼び出し、企業システムとの連携を許可する際の運用リスクに対応する。
Rubrik Code Guardianは第2のレイヤーを追加する。顧客のソースコードリポジトリをクローンしたコピーをエアギャップ環境で調査する。つまり、そのコピーは本番システムおよび外部ネットワークから隔離される。Rubrikによると、この設計により、稼働中のアプリケーションや機密ソースコードを不要な運用リスクにさらすことなく、積極的なセキュリティテストを実施できる。
同社のCode Guardianリリースによると、このシステムは専用のセキュリティハーネスを通じてClaude Mythos 5を使用する。このモデルは、各ファイルを独立した単位として検査するのではなく、複数段階にわたる脅威シナリオを推論することを想定している。
この違いは重要だ。重大な被害を招く脆弱性は、個別には比較的軽微な弱点の組み合わせから生じることが多い。あるサービスが安全でない入力を受け入れ、IDロールに過剰な権限があり、クラウドリソースに見落とされた経路から到達できる場合がある。従来型のツールは、攻撃者がそれらをどのようにつなげるかを示さずに、各条件を個別に報告する可能性がある。
Rubrikによると、Code Guardianはソースファイル、サービス、IDロール、クラウド境界を横断して、こうしたチェーンを特定する。その後、疑わしい経路が実際に悪用可能かをテストし、ビジネス上の重要度に応じて検出結果を評価する。
目的は、単に警告を増やすことではない。エンジニアリングチームが、どの警告に即時対応すべきかを判断できるようにし、アラート疲れを軽減することだ。
これはRubrikのセキュリティ上の立ち位置における重要な変化だ。同社は従来、データレジリエンス、保護されたバックアップ、攻撃後の復旧を重視してきた。Code Guardianにより、脆弱なアプリケーションが本番環境に到達する前の、ソフトウェアライフサイクルのより早い段階へと進出する。
Project Hourglassは、より広範な提供アライアンスにもなりつつある。AHEAD、Trace3、World Wide Technologyが、既存参加者であるCognizant、Deloitte、LTM、HCLTech、NTT DATA、Wiproに加わった。これらのパートナーは、企業がアーキテクチャを評価し、管理されたテストを実施し、既存の開発・セキュリティプロセスへ技術を組み込むことを支援できる。
Rubrikはインド・ゴアで開催されたGSI Summitでこの拡張を発表した。地理的な開催地より重要なのは提供モデルだ。大企業は、単一の開発チームが管理する孤立した製品トライアルではなく、システムインテグレーターを通じてセキュリティプログラムを購入することが多い。
したがって、Rubrik Code Guardianが運用上の統制策になるのか、興味深いプライベートプレビューのデモにとどまるのかは、パートナーが左右する可能性がある。パートナーはその結果を、チケットシステム、ソフトウェアパイプライン、ID管理、既存のアプリケーションセキュリティツールと接続する必要がある。
プライベートプレビューという位置付けは、この発表に明確な制約を課している。Rubrikによると、このサービスは選定された設計パートナーに「現状有姿」で提供される。一般提供ではなく、同社は説明されたすべての機能が商用リリースに到達することを保証していない。
この留保は記事の核心にある。Rubrikは野心的なアーキテクチャを示したが、顧客はまだ広範な導入データ、独立したベンチマーク、または安定した本番リリースを通じて評価できない。
AIコードセキュリティが企業のボトルネックになりつつある理由
圧力の背景には、自動化されたコード作成と人によるセキュリティレビューの間で広がる速度差がある。
AIコーディングアシスタントは、機能、テスト、設定ファイル、インフラコードを数分で生成できる。この速度は開発の経済性を変えるが、レビューの必要性をなくすわけではない。むしろ、リリース前にセキュリティチームが評価しなければならないコード量を増やす可能性がある。
リスクは、AIが生成したすべての関数に脆弱性が含まれるということではない。問題は、もっともらしいコードが短時間の目視レビューを通過しながら、権限、入力、依存関係、システム境界に関する危険な前提を残す可能性があることだ。
2025年のVeracode評価では、テスト対象モデルがタスク結果の45%で検出可能なOWASP Top 10脆弱性を導入したと報告された。同社のコードセキュリティ調査では、実装が安全または安全でないパターンに従いうる、管理されたプログラミングタスクを用いた。
この数値を、すべての本番ソフトウェアにおける脆弱性率として扱うべきではない。管理されたタスクは保守されている企業リポジトリとは異なり、結果は言語、プロンプト、モデル、テスト手法に依存する。それでもこの調査は、機能的な正しさがセキュリティ検証の代替にはなり得ない理由を示している。
リスクは生成されたソースコードだけに及ばない。コーディングエージェントは、リポジトリ、ターミナル、課題トラッカー、パッケージマネージャー、デプロイメントツールにアクセスできる。取得したコンテンツに埋め込まれた悪意ある指示は、過剰な権限を持つエージェントを誘導でき、通常のミスも多数のファイルに広がり得る。
OWASPは、モデルに不要な機能、権限、または自律性が与えられる状態を過剰なエージェンシーと説明している。過剰なエージェンシーに関するガイダンスでは、ツールアクセスの制限、権限の最小化、重大な操作に対する承認の要求、実行前の出力検証を推奨している。
これらの統制策は、エージェントに何を許可するかに焦点を当てている。Code Guardianは、関連する一方で異なる問いに対応する。人間とエージェントが貢献した後のコードベースに、どのようなセキュリティ上の弱点が存在するかという問いだ。
Rubrikは緊急性を説明するため、自社のZero Labs調査を引用している。同社によると、調査対象のサイバーセキュリティおよびITリーダーの86%は、AIエージェントの導入が1年以内に自組織のセキュリティガードレールを上回ると予想している。この数値はRubrikの調査に由来するため、読者はCode Guardianの有効性を独立して証明するものではなく、顧客の懸念を示す証拠として捉えるべきだ。
より広範な懸念は確立されている。自律型エージェントは、マシンID、認証情報、ツール権限を伴って動作し得る。また、人が各ステップをレビューするより速く、一連の操作を実行できる。
これにより、ソフトウェアリポジトリは攻撃対象領域の一部にすぎなくなる。セキュリティチームは、モデルのコンテキスト、エージェントの権限、生成されたコード、デプロイメントパイプライン、失敗した操作の影響を受けるデータを保護しなければならない。
Project Hourglassは現在、これらの複数レイヤーをカバーしようとしている。Rubrik Agent Cloudはエージェントの挙動と復旧に焦点を当て、Code Guardianはリポジトリ分析と攻撃チェーンの発見に焦点を当てる。Rubrikの既存レジリエンス製品は、予防策と実行時制御が失敗した場合の復旧レイヤーを提供する。
このエンドツーエンドの位置付けは商業的に魅力的だが、統合に関する疑問も生む。企業は既に、静的アプリケーションセキュリティテスト、ソフトウェアコンポジション分析、シークレット検出、クラウドセキュリティ態勢ツール、手動の侵入テストを利用している。
Code Guardianは、こうした製品では効率的に提供できない何かをもたらすことを示さなければならない。仮説上の弱点を見つけるだけでは不十分だ。このサービスには、攻撃者がどのように到達するのか、どの資産が露出するのか、そしてなぜその検出結果を競合する修正作業より優先すべきなのかを説明する必要がある。
ここで、AIコードセキュリティは優先順位付けの問題となる。意思決定を改善せずにアラート数を倍増させるスキャナーは、セキュリティプログラムを遅くしかねない。効果的な推論システムは、単により長いレポートを作成するのではなく、不確実性を減らさなければならない。
エンジニアリングリーダーにとって、直近の教訓は実践的だ。コード生成の高速化には、リポジトリ、ID、ランタイムの各レベルでより強固な統制が必要となる。チームには、アーキテクチャ上の判断、脅威に関する前提、修正作業について、長期的に残る記録も必要だ。
検索可能なエンジニアリングナレッジベースは、セキュリティ、開発、運用チーム間でそのコンテキストを維持できる。コードテストの代替にはならないが、レビュー担当者が、なぜ機密性の高いコンポーネントが特定の方法で設計されたのかを理解する助けになる。
Project Hourglassが攻撃チェーン推論とアラート量を対決させる
Rubrikの主な賭けは、AIが孤立した弱点を検査するツールよりも、現実的な攻撃経路を優先順位付けできるという点にある。
従来の静的解析は、アプリケーションを実行せずにソースコードを評価する。未サニタイズの入力、危険な関数呼び出し、脆弱な暗号方式といった、既知の安全でないパターンを特定できる。ソフトウェアコンポジション分析は、外部パッケージと依存関係に含まれる既知の脆弱性を検査する。
これらの手法は、再現性が高く、広く理解されており、自動化された開発パイプラインに適しているため、依然として不可欠だ。しかし、偽陽性や、ビジネス上の文脈を欠く孤立した検出結果を生む場合がある。
到達不能なテストコンポーネント内の警告は、インターネットに公開された認証サービスにある悪用可能な欠陥と同じリスクを持たない。それでも、人や別のシステムが周辺アーキテクチャを再構築しない限り、両者は同じキューに表示され得る。
Rubrik Code Guardianは、より多くの再構築を実行するよう設計されている。同社によると、そのモデルはファイルとサービスを横断して推論し、ID関係を含め、クラウド境界を考慮できる。生成される出力は、切り離された欠陥ではなく、攻撃チェーンを説明することが想定されている。
3つの弱点を持つ仮想的なエンタープライズアプリケーションを考えてみよう。あるAPIは不適切に検証されたパラメータを受け入れ、あるサービスIDは機密性の高いストレージバケットを読み取れる。そしてバックグラウンドワーカーはAPIからのメッセージを信頼する。
ファイル単位のスキャナーなら、3件のチケットを起票するかもしれない。攻撃チェーン分析では、攻撃者がパラメータの欠陥を利用してメッセージを制御し、ワーカーを起動し、サービスIDを継承してストレージバケットに到達できるかを問う。この一連の流れが隔離されたコピー内で成立すれば、セキュリティチームはより明確な修正優先順位を得られる。
これが、Rubrikが掲げる事業インパクトの主張を支える仕組みだ。モデルの価値は、より多くのコードを読めることだけにあるのではない。理論上の組み合わせと実行可能性のあるチェーンを区別し、その結論を人間のレビュアーに説明できる場合に有用になる。
Anthropicはすでに、高度なコーディングモデルによる支援型の脆弱性発見を防御的な活用例として提示している。2026年2月、同社はClaude Code Securityが本番運用中のオープンソースプロジェクトで500件超の脆弱性を発見したと述べた。セキュリティ研究に関する発表では、モデル分析と人間によるレビュー、協調的な脆弱性開示を組み合わせるプロセスが説明されている。
Anthropicは、外部トリアージとメンテナーのレビューを経た発見事項を記録する脆弱性ダッシュボードも公開している。このワークフローが重要なのは、モデルが最初に抱いた疑いが、確認済みの脆弱性と同義ではないためだ。
Rubrikは、この一般的な能力を管理されたエンタープライズ環境へ持ち込もうとしている。Code Guardianは、公開オープンソースリポジトリをスキャンするのではなく、参加パートナーを通じて顧客の非公開コードを調査することを意図している。
エアギャップされたクローンには、2つの潜在的な利点がある。第一に、独自コードが外部サービスへ漏洩したり、本番稼働中のシステムに到達したりする可能性を抑えられる。第二に、顧客や業務に影響を及ぼさず、テストプロセスが積極的な検証を行える余地を生む。
ただし、隔離によってすべてのセキュリティ上の疑問が解決するわけではない。企業は依然として、リポジトリのコピーをどのように作成するのか、モデル推論がどこで実行されるのか、結果をどのように保持するのか、またどのパートナー担当者が調査結果にアクセスできるのかについて詳細を必要とする。
「エアギャップ」という用語も、異なる技術的構成を指し得る。物理的に分離された環境、厳しく制限されたプライベートクラウド、論理的に隔離されたネットワークは、同一の保証を提供しない。Rubrikの公開発表には、これらのモデルを比較するために十分なアーキテクチャ詳細がない。
競争上の試金石は、証拠の品質にある。既存のアプリケーションセキュリティベンダーは、既存スキャナーにAIによる説明と文脈に基づく順位付けを追加できる。クラウドセキュリティベンダーは、本番テレメトリーを用いてID、サービス、到達可能な資産を相関付けられる。
Rubrikは異なる資産を持つ。保護対象のエンタープライズデータ、リカバリーワークフロー、サイバーレジリエンスをめぐる関係性だ。Project Hourglassは、コード分析をより広範なインフラ意思決定と結び付けられるシステムインテグレーターパートナーも提供する。
Rubrikの戦略が最も強く機能する形は、これらの資産を組み合わせることだ。Code Guardianがチェーンを特定し、Agent Cloudがエージェントの振る舞いを制約し、Rubrikのリカバリー制御がインシデント後に影響を受けたコードやデータを復元する。
弱い形では、重複するアラートを出す別のコンソールが増えるだけになる。プライベートプレビューの顧客は、自分たちがどちらの結果を見ているのかを見極める必要がある。
難題はAIレビュアーの検証にある
AI支援で作成されたコードをAIシステムがレビューすると、モデルの確信度だけでは解決できない検証ループが生じる。
Rubrikは、Code Guardianが実際の悪用可能性について検出結果を検証するとしている。これは、不審なパターンを特定するよりも厳しい主張だ。悪用可能性は、構成、デプロイ状態、到達可能な入力、ID権限、環境制御に左右される。
クローンされたリポジトリには、本番環境を再現するために必要なすべての事実が含まれていない可能性がある。インフラ設定は別のシステムに存在し得る。実行時IDは宣言済みロールと異なる場合がある。ネットワークポリシーはクローン作成後に変更されることもある。
つまり、システムが示す攻撃経路は論理的に一貫していても、本番環境では実現不可能な場合がある。逆の問題も存在する。リポジトリ中心のテストでは、実行時の乖離、文書化されていない統合、侵害された認証情報によって生まれた危険な経路を見落とす可能性がある。
したがって、プライベートプレビューの試行では、発見された問題数以上を測定すべきだ。確認済みの悪用可能なチェーン、却下された検出結果、重複アラート、検証までの時間、修正時間、システムが見逃した欠陥を追跡する必要がある。
独立した比較は特に重要になる。設計パートナーは、既存のスキャナーやペネトレーションテストのプロセスと並行してCode Guardianを運用すべきだ。これにより、サービスが固有のリスクを発見しているのか、既知の検出結果を再パッケージ化しているだけなのかを判断する基準が作られる。
セキュリティチームには、再現可能な証拠も必要だ。有用なレポートは、関連するコードパス、必要な権限、前提条件、影響を受ける資産、チェーンの検証に使用した手順を特定すべきである。レビュアーは、ブラックボックスのリスクスコアを受け入れずに、モデルの推論へ異議を申し立てられなければならない。
Rubrikは、偽陽性率、偽陰性率、リポジトリのカバレッジ、分析時間、脆弱性クラスに関するベンチマーク結果を公表していない。また同社の発表では、大規模モノレポジトリや一般的でないプログラミング言語でパフォーマンスがどのように変化するかも明らかにされていない。
これらの情報欠落は初期プレビューとしては妥当だが、企業が導ける結論を制限する。Code Guardianは提案されたセキュリティ制御であり、既存のアプリケーションセキュリティテストを独立して検証済みの形で置き換えるものではない。
基盤となるモデルは、別の集中リスクも生む。Rubrikは、Claude Codeや他のAIアシスタントによって作成された可能性のあるコードを検査するためにAnthropicの技術へ依存している。有能なモデルであっても、コードを生成したシステムと盲点を共有する可能性がある。
モデルの多様性がこの問題を自動的に解決するわけではないが、独立したテスト手法は役立ち得る。決定論的スキャナー、人間によるペネトレーションテスター、実行時の観測、別モデルはそれぞれ異なる前提に異議を唱えられる。
OWASPのより広範なエージェントセキュリティフレームワークは、エージェント型システムをモデル、ツール、ID、メモリ、外部サービスの組み合わせとして扱う。この視点は、単一の自動化レビュアーに依存すべきでないことを示している。
ガバナンス上の問題もある。モデルが経路を事業上重要だと判断できるのは、事業上の重要性に関する正確な情報を受け取る場合に限られる。リポジトリだけでは、どのサービスが規制対象データを処理するのか、大口顧客を支えているのか、重要な業務ワークフローを制御しているのかが明らかにならない場合がある。
パートナーはこの文脈を提供する必要がある。そのためには、アプリケーション所有者、セキュリティチーム、クラウド管理者、IDチーム、事業責任者の協力が求められる。
システムインテグレーターはこれらのグループを調整できるため、Rubrikがアライアンス優先戦略を取る理由の説明に役立つ。しかし、実装慣行が異なれば、パートナー主導の提供は結果のばらつきを生み得る。認定制度や直接的なエンジニアリング支援はこのばらつきを抑える可能性があるが、Rubrikはまだ運用成果データを公表していない。
同社のリカバリーに関する位置付けも精査に値する。インスタントコードベースリカバリーは、意図しない変更後に既知の正常なファイルを復元できるが、コードの復元がすべての結果を自動的に取り消すわけではない。
侵害されたエージェントは、シークレットを露出させ、外部取引を実行し、サードパーティーシステムを変更し、本番データを改変する可能性がある。こうした影響には、リポジトリのロールバックを超えるインシデント対応が必要となる。
したがって、Project Hourglassは保証ではなく、多層的な制御として評価すべきだ。ガードレールは危険な行為を減らせる。コードテストは脆弱な経路を発見できる。リカバリーは被害を限定できる。いずれも最小権限アクセス、人間による承認、安全な開発プラクティス、インシデント計画の必要性をなくすものではない。
これが中核となるトレードオフだ。AIの推論は、ルールベースのツールでは結び付けにくい関係を調査できるが、その推論自体にも検証が必要である。企業が速度を得られるのは、検証の負担が自動化する問題より小さくなる場合だけだ。
Rubrik Code Guardianはいま3つの試験を通過しなければならない
次に必要な証拠は、導入結果、独立比較、明確に定義された本番アーキテクチャから得られる。
最初のシグナルは、設計パートナーによる成果の質だ。AHEAD、Trace3、WWT、そして既存のProject Hourglass参加者は、複雑なリポジトリと成熟したセキュリティプログラムを持つ企業にアクセスできる。
最も有用な結果は、「より多く」のリスクを発見したという宣伝文句ではない。購入者が必要とするのは、既存ツールが見逃した攻撃チェーン、Code Guardianがそれらをどのように検証したか、チームがどれほど迅速に修正を完了したかを示す匿名化された事例だ。
確認済みの検出結果は、モデルベースの推論が優先順位付けを改善するというRubrikの主張を強める。高い却下率や大きなレビュー負荷は、それを弱めることになる。
2つ目のシグナルは、プライベートプレビューから一般提供へ至る道筋だ。Rubrikの現行リリースには、Code Guardianが変更される可能性、提供が遅れる可能性、または一般提供されない可能性があるという明示的な警告が含まれている。
本番リリースでは、対応言語、リポジトリサイズの上限、導入モデル、データ処理、モデル更新ポリシー、保持制御、開発パイプラインとの統合を明確にすべきである。また、顧客がテスト中に実行されたアクションをどのように監査するかも説明する必要がある。
一般提供だけで有効性が証明されるわけではない。しかし、安定したドキュメントと契約上のセキュリティコミットメントは、Rubrikが管理された実験を超える準備ができていることを示すだろう。
3つ目のシグナルは競合の反応だ。アプリケーションセキュリティおよびクラウドセキュリティのベンダーはすでに、コードスキャナー、脆弱性データベース、依存関係インテリジェンス、本番環境の文脈を保有している。これらのベンダーには、エージェント型の攻撃チェーン分析を追加する明確な動機がある。
これらのベンダーが、顧客がすでに使っているツールを通じて同等の推論を提供するなら、Rubrikはリカバリー、隔離、あるいはパートナーによる提供で差別化する必要がある。競合がコードとID、事業インパクトの相関付けに苦戦するなら、Project Hourglassはより強い機会を得る。
Anthropic自身のセキュリティ製品も、もう1つの比較対象となる。Claude Code Securityは、モデル提供者が脆弱性発見を直接的な製品カテゴリーと見なしていることを示す。Rubrikは、自社のセキュリティハーネス、エンタープライズの文脈、リカバリーアーキテクチャが、基盤モデルへのアクセスを超えてどのような価値を加えるのか説明しなければならない。
開発者とエンタープライズの購入者は、Rubrik Code Guardianを確立された制御として扱う前に、これらのシグナルを見守るべきだ。この発表は現実の問題を特定し、信頼できる仕組みを提案しているが、証拠はなお予備的な段階にある。
開発チームにとって、実務的な対応は1社のベンダーのリリースを待つべきではない。コーディングエージェントがどこで稼働しているかを棚卸しし、その認証情報を制限し、重大な変更を記録し、機密性の高い操作に対する人間の承認を維持することだ。AIレビュアーが利用可能な場合でも、決定論的スキャナーと独立したテストを継続すべきである。
セキュリティリーダーは、さらに難しい問いも投げかけるべきだ。新しいツールは、発見から検証済みの修正までの道のりを短縮するのか。高度なチェーンを発見してもレビュアーを圧倒するシステムは、運用上のボトルネックを解消しない。
Project Hourglassが、モデルの推論をエンジニアが行動に移せる再現可能な証拠へ変換できるなら、Rubrik Code Guardianは重要になる。そのプライベートプレビューは、この試験の始まりであり、結果ではない。今後数か月、購入者は検証済みの攻撃チェーン、透明性のあるエラー率、そして検査対象のコードを保護する本番アーキテクチャを求めるべきだ。
