10月のアップデート動画を見る
72秒の概要動画は、英語、フランス語、スペイン語、日本語、簡体字中国語から選べます。各バージョンには、ローカライズされた画面上のテキストと字幕が付いています。動画に映っている製品のインターフェースは英語です。
Download this video · Read the transcript · Download captions
評価中の危険な操作を制御するための人間による承認を追加し、トリアージや複雑なコンプライアンス業務のための自律的な自動化を構築する新しい方法としてTicket Agentを導入しました。また、スキャンの設定、調査ツール、検出結果に対するアクションを拡張し、チームが問題をテストから修復、再テストまで一貫して進められるようにしました。
今回のリリースは、9月の変更履歴以降に追加された内容を扱います。
危険な操作を制御する承認機能を追加
エージェントがSQLインジェクションの可能性を見つけ、「このSQLインジェクションの悪用を進めてよいですか？」と尋ねます。潜在的に危険な操作をどう進めるかを判断できるよう、人間による承認を追加しました。新しいApprovalsタブでは、Approve（承認）、Deny（拒否）、またはカスタムの指示を与えることができます。たとえば「ステージング環境で読み取り専用の実証を行うこと。顧客データは抽出しないこと」といった指示です。
待機中のインジケーターが、未回答のリクエストを強調表示します。承認の待機中も、ほかのテストは続行されます。ブロックされるのは、その判断を待っている操作だけです。同じ会話を通じて、アプリケーション固有の手順についてエージェントにコンテキストを与えることもできます。
未回答の承認リクエストの扱いを選択する
エージェントが判断を求め、レビュー担当者が誰も回答しなかった場合にどうするかを選べるよう、承認モードを追加しました。
| レビュー担当者が… | 選択するモード | エージェントが判断を求めたとき… |
|---|---|---|
| 求められた操作が進む前に回答する必要がある | Ask and block without an answer | 時間内に回答がなければ、求められた操作だけがブロックされたままになります。ほかのテストは続行されます。 |
| ガイダンスは出せるが、不在時にはスキャンを続行させたい | Ask and proceed without an answer | 時間内に回答がなければ、エージェントはその操作を進められます。 |
| エージェントに入力を求めずに作業させたい | Run without asking | エージェントは人間の入力を求めません。 |
これらのモードは、エージェントが求めた判断を制御するものであり、すべてのツール呼び出しを自動的に一時停止してレビューにかけるわけではありません。これらの制御は、対応するAgentic Deep Scan、Mobile Shielding、Single Vulnerability Assessmentのプロファイルに追加しました。また、Dig Deeperを拡張し、選択したモードをフォローアップの評価に引き継げるようにしました。
スコープとトラフィックの制御でスキャン設定を拡張
エージェント型の評価に、より完全なテストの指示書を渡せるよう、スキャン設定を拡張しました。どのアプリケーションをテストするか、どのアカウントを使うか、どのネットワークを除外するか、どの程度のトラフィックが適切か、といった内容です。
| 指示書で答える問い | 指定する場所 |
|---|---|
| テストをどこに集中させるか | Scope whitelist：許可するドメイン、ワイルドカードドメイン、IPアドレス |
| 絶対に接続してはならないネットワークはどれか | Outgoing IP/CIDR blocklist：それらのアドレスとネットワークに対するファイアウォールの除外設定 |
| テスターがほかに知っておくべきことは何か | Additional instructions：アプリケーションのコンテキスト、テストアカウント、追加の要件、避けるべき操作や環境 |
| どの程度のトラフィックが適切か | 対応するプロファイルのAdvanced SettingsにあるQPS (queries per second)。リクエストレートの上限は、文章による指示とは別に設定します。 |
| リスクのある操作の前に何をすべきか | Approval of actions：「run without asking」「ask and block without an answer」「ask and proceed without an answer」のいずれか |
これらの制御は、異なるレベルで機能します。ホワイトリストはプロンプトを通じてエージェントを誘導し、IP/CIDRのブロックリストはファイアウォールのルールとして強制されます。スコープの監視は、これとは別にエージェントの出力を評価して逸脱を検知し、アラートを発します。オプションで攻撃側のエージェントを停止することもできます。ガードレールの設定は、新しいスキャンごとにリセットされます。スコープの指示への対応を、関連するリポジトリ、マルチアセット、ネットワークのスキャンフローにも拡張しました。
モバイルの準備状況チェックを追加し、調査ツールを拡張
評価のカバレッジを解釈する前に、インストール、画面へのアクセス、認証の問題を明らかにするモバイルの準備状況チェックを追加しました。ビルドがインストールやログインを通過できない場合は、まずセットアップの問題を調査できます。インフラの障害は新しい端末で再試行でき、アプリケーションが原因のインストール失敗は端末の問題と区別されます。準備状況チェックの失敗によって、すべてのスキャンが自動的にブロックされるわけではありません。
端末のセッションの復旧機能を拡張し、探索中にセッションが途切れた場合でも、エージェントがエントリポイントに再びアクセスし、対象アプリをフォアグラウンドに戻せるようにしました。セッション認証を伴う端末の操作により、準備作業とエビデンスの収集がつながります。オンデマンドで利用できるroot化済みのAndroidエミュレーターと、拡張されたAndroid/iOSのトレース、ログ、復号済みコード、アプリケーションデータのツールが、より深い調査を支えます。FlutterとJDWPに関する修正により、不完全な計装データと再接続の問題に対処しました。
アプリケーションには、RustのコンポーネントやSwiftのソースなど、異なるテスト手法が必要なコードが含まれている場合もあります。構造化されたソースの推論をC++、Rust、Swiftに拡張し、依存関係を考慮した計画立案と、ネイティブコードに特化した概念実証（PoC）の実行に対応しました。読み取り専用の露出チェックの対象を広げ、より多くのエンタープライズ製品、SMB、WebLogic T3、SMTPをカバーしました。露出のシグナルは、確定した悪用とは区別して扱われます。
自律的な自動化のためのTicket Agentを導入
Ticket Agentを導入しました。脆弱性のトリアージから複雑なコンプライアンスのワークフローの実行まで、自律的な自動化を実装するための新しい高度な方法です。エージェントに指示、再利用可能なスキル、接続したツール、イベントのルールを与えれば、本来なら手作業での調整を繰り返す必要がある手順を、エージェントが進められるようになります。
トリアージであれば、チームの基準に照らして検出結果をレビューし、元のエビデンスを集め、次のアクションを準備するといったことが考えられます。コンプライアンスであれば、エージェントがコントロールのチェックリストに従い、裏付けとなるエビデンスをまとめ、ギャップを特定し、レビュー用の成果物を準備できます。
設定できるワークフローの例をいくつか紹介します。
| 繰り返し発生する作業 | 作成できるエージェントの例 |
|---|---|
| 完了したスキャンのすべてに、チームのトリアージルールを適用する必要がある。 | スキャン完了をトリガーにして、関連する検出結果を重大度と担当の基準に照らしてレビューし、トリアージの要約を準備します。 |
| 誤検知の可能性が報告される。 | コメントイベントと、一致するタグまたはステータスの条件を使ってエビデンスのレビューを開始します。必要な評価ツールが接続されていれば、検証を依頼し、その結果を自社のレポート形式でまとめてレビューにかけます。 |
| 監査のエビデンスに、毎回同じ構成が求められる。 | Complianceテンプレートから始め、コントロールのチェックリストをスキルとして追加し、接続したツールでエビデンスを集め、ギャップを特定し、コンプライアンスの成果物をレビュー用に準備します。 |
| 優先度の高いチケットがSLOの期限に近づいている、または超過している。 | SLO超過のルールまたはスケジュールされたルールを使って最新のコンテキストを集め、エスカレーションの要約を準備します。 |
| 再オープンされたチケットに、もう一度調査が必要である。 | 再オープンをトリガーにして、現在のエビデンスを過去の議論と比較し、何を見直す必要があるかを説明します。 |
これらは、自社のプロンプト、条件、接続したツールで設定するための例です。誤検知の報告は調査のきっかけであり、エージェントはステータスの変更を推奨する前に、検証のエビデンスを記録する必要があります。
AI AgentsワークスペースにTicket Agentの設定を追加しました。ここでは、ジョブごとにモデル、指示、再利用可能なスキル、オプションのGitベースのメモリ、MCPツールを選択できます。Vulnerability TriageとComplianceのテンプレートが出発点となります。これらのルールは、レビューのために無効の状態で始まります。
このワークフローを試すには、まずAssignee is This agentを条件とするAssignedルールから始めます。テスト用のチケットを割り当てて結果を確認し、ルールの対象を広げる前にプロンプトを調整してください。エージェントは人間の担当者と並行して作業できるため、問題の責任を持つエンジニアが見える状態を保ちながら、エージェントが調査を手伝えます。
ほかのルールでは、チケットの作成、再オープン、コメント、SLOの超過、スキャンの完了、スケジュールに反応させることができます。条件を使えば、優先度、ステータス、ストリーム、タグ、担当者、スキャンプロファイル、ターゲットで作業を絞り込めます。再利用可能なスキルには、文章による指示、GitHubのフォルダー、アップロードしたアーカイブを含められます。ツールは、リモートのMCPサーバー、ローカルのプロセス、OXOから利用できます。設定とルールの例については、Ticket Agentのセットアップガイドをご覧ください。
トリアージ会議の最中に、複数のチケットのストリームのデータをまとめて更新する必要が生じることがあります。すでにRemediation Streamsを使っているチーム向けに、スプレッドシート編集を拡張し、複数セルの選択と一括コピー/ペーストに対応しました。タイムラインのページネーションにより、大量のストリームも移動しやすくなります。セットアップについてはStreamsのガイドをご覧ください。
調査と検出結果のトリアージを拡張
モバイルのレポートに検出結果が届きます。エンジニアが最初に抱く疑問は実務的なものです。「テストはどうやってその画面にたどり着いたのか。再現手順をたどれるか。影響を受けるコードは自社のものか、それともSDKのものか」。こうした疑問に、問題をチームに引き渡す前に答えられるよう、リプレイと担当区分の制御を追加し、Copilotが扱う検出結果のコンテキストを拡張しました。
エビデンスをたどってアプリケーションまで戻る
既存の探索マップにコールカバレッジのリプレイを追加し、アプリケーション内でたどった経路を追えるようにしました。スクリーンショット、キャプション、分岐するタイムラインが、記録されたナビゲーションの順序を示します。ログインが必要な画面の検出結果であれば、その画面に至る経路を確認できます。検索とステータスのフィルターで操作を見つけられ、サイズを変更できるタイムラインと既存のマップビューを使って、順序とより広い探索範囲の間を行き来できます。
アプリケーション内の経路をリプレイし、ステップのコンテキストを読み、分岐するタイムラインを移動できます。
次の質問、たとえば「このトレースと、再現に必要な手順を説明して」に答えられるよう、Ask Copilotを拡張し、選択した検出結果を会話に引き継げるようにしました。詳細を新しいチャットにコピーしなくても、画面上の問題から始められます。Copilotは進行状況、ツールの実行、ターミナルのアクティビティをストリーミングで表示するため、調査を追いかけたり、別の質問をキューに入れたり、リクエストをキャンセルしたりできます。拡張された脆弱性ツール、スキル、メモリ、より長いツールの出力により、Copilotが扱えるコンテキストが増えました。
Ask Copilotは、選択した検出結果がすでにコンテキストに含まれた状態で会話を開きます。ここではDIVAのデモアプリケーションで示しています。
対応が必要な検出結果をノイズから切り分ける
トレースがバンドルされたSDKの中に続いている場合、アプリケーションチームはその問題をSDKのベンダーに伝える必要があるかもしれません。その担当区分の判断を助けるため、ファーストパーティかサードパーティかの分類とフィルターを追加し、場所のドリルダウンとSDKのコールトレースも用意しました。分類を修正したり、サードパーティの検出結果の報告をOstorlabに依頼したりできます。関連するワークフローについては、検出結果のレビューガイドで説明しています。
担当区分の制御により、アプリケーションの検出結果とサードパーティの検出結果を区別できます。
同じプレースホルダーの認証情報を何度も却下したり、重複した依存関係のアドバイザリを確認したりすることは、トリアージを難しくします。シークレット解析を拡張し、より多くのプレースホルダーやクライアント設定の値を除外するようにしました。依存関係のアドバイザリは重複排除され、修正済みバージョンの情報が含まれます。バージョンが固定されていない依存関係は、架空のバージョンを割り当てるのではなく、スキップされます。モバイルの解析では、Fragmentが保持する状態と難読化されたAndroidのフラグメントも認識し、AndroidX Biometricのダミー暗号に関するアラートを抑制し、フレームワークのバンドルに含まれるATSの設定と、ループバックやエミュレーター専用の平文通信の例外を除外します。
ストレージに関する検出結果をレビューするエンジニアは、認証情報が実際に平文で書き込まれたかどうかを知る必要があります。実行時のストレージ解析は、AndroidのSharedPreferencesへのそうした書き込みを検出し、値をマスクし、プレースホルダーと暗号化された値を除外します。TLSの要件を確認するチーム向けには、拡張されたプロトコル、暗号スイート、CRYPTREC/IPAのチェックにそれぞれ個別の説明があり、プロファイルへの不適合は、実証された悪用可能性とは分けて報告されます。
検出結果に対するアクションを追加し、修正の検証を拡張
検出結果から、修正の検証の開始、サードパーティへの報告の依頼、接続されたリポジトリでの修正の着手を行えるアクションを追加しました。再テストを拡張して未リリースのモバイルの候補ビルドを受け付けるようにしたため、パッチをアプリストアに公開する前に評価できます。
検出結果から次のアクションを始める
検出結果を開いています。次のステップは、パッチの検証かもしれませんし、ベンダーへの開示をOstorlabに依頼することや、接続されたリポジトリで修正を実装することかもしれません。こうした作業は、エビデンスがすでにある場所から始められるべきです。
- パッチの準備ができたら、Verify Fixをクリック。指示書を作り直すのではなく、検出結果から再テストを開始します。モバイルアプリの場合、元の評価でアプリストアのバージョンを使っていたとしても、パッチを適用した候補ビルドをアップロードできます。
- 問題がSDKにあるなら、Ask Ostorlab to Reportをクリック。サードパーティの検出結果の報告をOstorlabに依頼できます。チームがベンダーのために問題を一から再構成する必要はありません。
- リポジトリが連携済みなら、検出結果から修正のアクションを開始。接続されたコードと検出結果のコンテキストを使って修正の実装を依頼し、その結果の変更を通常のエンジニアリングのプロセスでレビューします。
「ワンクリック」は作業の出発点です。その後に、スキャナーやターゲットの選択、確認、レビューが続く場合もあります。狙いは、コンテキストの収集、調査、次のステップの準備を、手作業のToDoリストから外すことです。
たとえば、Androidのエンジニアが候補となるパッチを用意しているものの、アプリストアのバージョンにはまだ問題が残っているとします。従来の診断であれば、新しいビルドをペンテスターに送り、元のPoCをもう一度試してバイパスがないかを調べるよう依頼するでしょう。Verify Fixは、その引き継ぎの出発点を検出結果の中に用意します。
Verify Fixを追加し、検出結果の場所と弱点の分類に加えて、元のPoCを再テストし、考えられるバイパスを調査するよう指示したうえで、Single Vulnerability Assessmentを開始できるようにしました。元のスキャンでアプリストアのバージョンを使っていた場合でも、候補となるモバイルのビルドを直接アップロードできます。パッチを公開する前に評価し、更新されたターゲットに到達できるスキャナーを選択できます。
検出結果を開き、Verify Fixを選び、スキャナーを選択して、更新されたターゲットまたはビルドを指定します。このワークフローは、モバイル、Web、ネットワークの検出結果に対応しています。その判定はベストエフォートの評価です。問題をクローズするかどうかを決める前に、得られたエビデンスを確認してください。
共有している依存関係の更新が複数のアプリケーションにまたがる検出結果に対処する場合、見直すべきリスクの集合ができるかもしれません。その集合を見つけるためのサーバーサイドの検索、並べ替え、ステータスのフィルターに加えて、ページをまたいだ選択と、フォローアップの評価をまとめて起動するリスクの一括再実行を追加しました。マルチアセットのフォローアップでも、元の影響を受けたアセットがよりよく保持されるようになりました。
MCPと連携の制御を拡張
あるエンジニアが、コーディングアシスタントでチケットを開き、修正の手助けを求めます。貼り付けた説明文には、問題を説明するHTTPのやり取りやスタックトレースが含まれていないかもしれません。一方で、セキュリティチームはスキャンの更新情報を自分たちのシステムに届ける必要があります。エビデンスとスキャンのワークフローをこうしたツールに取り込むための接続を拡張しました。
コーディングアシスタントがエビデンスを調べ、それに基づいて動けるように
9月に導入したOstorlab Platform MCP Serverを拡張し、接続されたコーディングアシスタントが、検出結果の背後にあるエビデンスをより多く取得できるようにしました。HTTPトラフィック、パケットキャプチャ、スタックトレース、ソース、ログ、コールカバレッジのノード、アセットの詳細です。これにより、エンジニアが修正に取り組む間も、調査で元の資料にアクセスできます。
接続されたクライアントは、対応するモバイル、TestFlight、リポジトリ、ソースアーカイブ、ディスカバリー、マルチアセットのスキャンを作成し、アップロードしたファイルをステージングし、予算を設定することもできます。すでにスキャンのワークフローを自動化しているチーム向けに、MCPは、対応するCSV、SARIF、スキャンアーカイブのエクスポート、連携の設定とテスト、スキャナーグループ、監視スケジュール、修復エージェントのリソースの管理を提供するようになりました。利用できるツールは、APIキーの権限と製品の構成によって異なります。クライアント、アップロード、ページネーションについては、MCPのセットアップガイドで説明しています。
配信とリポジトリへのアクセスを組織に合わせる
スキャンの通知を、承認された送信元からのトラフィックだけを受け付け、ペイロードのフィールドもいくつかしか必要としない内部サービスに送っているとします。Webhookを拡張し、その受信側に送るスキャンのフィールドを選択し、送信先にわかりやすい名前を付け、欧州または米国からの送信（egress）を選べるようにしました。テストは選択したリージョンのバックグラウンドジョブを使うため、セットアップ中に、受信側の許可リストに対して配信経路を確認できます。
プラットフォームチームがすでにGitHub AppのIDと認証情報のローテーションを管理している場合、リポジトリの連携に顧客所有のGitHub Appを使えるようになりました。インストールの設定、Appの名前の変更、認証情報のローテーション、インストールの無効化や削除を、使い慣れたライフサイクルで行えます。カスタムのインストールはAppの認証情報で検証され、Ostorlab Appの接続ではGitHub OAuthを通じてユーザーのアクセスが検証されます。対応するインストールは、承認された複数のOstorlabの組織に接続できます。GitHub連携のガイドをご覧ください。
定期的な評価とモデルの接続を拡張
来月の評価は、アプリケーションが変わった後に始まります。ログインフローが変わり、別のサービスがスコープに加わり、チームは前回のスケジュール実行で何が起きたかを知る必要があります。再び担当するペンテスターには、更新された指示書が必要です。同じ理由で、定期的な評価には、維持された知識と実行の明確な記録が必要です。
知識を最新に保ち、テストが失敗したときにそれを把握する
保持している知識のエントリが古いログインフローを説明したままなら、その古いコンテキストを後の作業に持ち込むのではなく、編集できるようになりました。永続的なスキャンの知識は、エントリの追加、編集、削除に対応しています。フォルダーを段階的に閲覧できるため、ツリー全体を読み込まなくても、大きな知識のワークスペースを確認できます。
毎週の評価にモバイルアプリ、そのバックエンド、その他のアセットが含まれる場合、定期的なマルチアセット評価で、種類の異なるアセットの集合とアタックサーフェスのチェックをスケジュールできます。スケジュールされた実行が失敗した場合、監視の履歴にその実行ステータスと展開可能な失敗の詳細が表示されるようになり、調査の出発点になります。監視のガイドをご覧ください。
次のステータス会議に向けて、Cockpitは保留中のアクション項目と日次の変更の要約を表示します。レポートには、より明確な攻撃シナリオの要約、PDFへの組織のロゴの表示、タスク、レポート、トランザクションメッセージ全体での対応言語の拡大が加わり、次のステップを担う人々と評価を共有しやすくなりました。
消費量を計画し、モデルの推論を実行する場所を選ぶ
次の評価を依頼する前に、チームはそのスコープと消費量を計画する必要があります。スキャンの消費量の見積もりと、対応するトークンおよびリスクの予算が、その計画に役立ちます。Copilotの見積もりカードには、現在のターゲットとプロファイルがあらかじめ入力されるので、それを確認できます。ウォレットのトークンは数量を指定して購入できます。前払いの修復エージェント用モデルは同じ組織のウォレットを使い、自社のプロバイダーキーを使う選択肢も引き続き利用できます。
チームがすでにOllamaやOpenAI互換サーバーでモデルを提供している場合、BYOKでそのサービスに接続できるようになりました。vLLM、LM Studio、llama.cppによるデプロイも含まれます。エンドポイントのURL、モデル名、必要に応じてAPIキーを設定します。サーバーにはスキャナーから到達できる必要があります。対応する自律テストのエージェントとモバイル探索のエージェント、そしてOXOが、これらの接続を利用できます。
推論の接続が決めるのはモデルの推論を実行する場所であり、プラットフォームのオーケストレーション、検出結果、レポートの場所が移るわけではありません。スキャナーの設定とあわせたセットアップ方法は、BYOKのガイドで説明しています。
一時的なアップロードの失敗によって、テストが終わった後もチームが検出結果を待たされることもあります。検出結果のアップロードの再試行と、失敗したバッチの復旧を改善し、その受け渡しの問題に対処しました。信頼性の向上は、認証済みのクロール、ロールアウト中のAPI接続、スキャナーのクリーンアップ、端末の健全性の監視にも及びます。Copilotのシークレットのマスキングの拡張、組織単位に限定したアセットと知識の操作、より厳格な連携の権限が、これらのワークフローを支えます。
日常的に使う画面の改善を追加
スキャンのタブを切り替え、検出結果をまとめてトリアージし、同じストリームの値を複数のチケットに貼り付け、作業が中断された後に元の作業に戻る。こうした慣れた作業の手間を減らすため、次の操作を追加し、既存のビューを拡張しました。
| こんなとき… | 簡単になったこと |
|---|---|
| 大量のリスクの一覧を処理する | サーバーサイドの検索、並べ替え、ページネーション、複数ステータスのフィルター、ページをまたいだ選択、一括再実行 |
| 検出結果の中を移動する | 固定表示されるセクションタブ、より広い検索欄、選択内容に応じたトリアージメニュー、ドロワー内のリスク評価と説明 |
| スキャンを共有する、またはスキャンに戻る | 開いているスキャンのタブがURLに保持される |
| スプレッドシートでチケットを編集する | 複数セルの選択、一括コピー/ペースト、ストリームの作成と編集、Delete/Backspaceによるクリア、下書きの保持と復元 |
| 割り当てられた作業に戻る | My ticketsのショートカットと、編集中も保持されるフィルター |
| 大きなワークスペースの中を移動する | 知識のフォルダーが段階的に読み込まれ、展開したファイルツリーがスクロールし、選択したファイル名が見え、画像のプレビューが縦横比を保つ |
| コンテキストを切り替える | パンくずリストのスイッチャーで現在の項目が先頭に表示され、ドロップダウンの動作がより一貫している |
| スキャンを作成する | 必須、推奨、任意の手順がより明確に。プロファイル固有の設定、プラットフォームのバッジ、より明確なターゲットの識別子 |
| 探索を追う | 既存のマップと並ぶ、リプレイの検索、ステータスのフィルター、サイズを変更できるタイムライン |
| 通知を設定する | 名前付きのWebhook、選択可能なペイロードのフィールド、リージョンごとの配信、保存済みのWebhookのより明確なテスト |
| Copilotの作業を追う | 進行状況とターミナルのアクティビティのストリーミング表示、フォローアップの質問のキュー、キャンセル |
| セクションの読み込み中にレポートを読む | バックグラウンドでの読み込みにより、タブの移動の応答性が保たれる |
舞台裏：より良いコンテキストと、今後の予定
調査に役立つコンテキストを保持するメモリ
後の評価では、以前の作業で得た役立つメモやPoCのファイルを引き継げるべきです。同じ評価の中のエージェントも、コンテキストを何度も再発見するのではなく、調査について共通の見方を持つ必要があります。
この課題に向けて、ワークスペースのメモリを拡張しました。保存したファイルを共有ワークスペースに復元すること、新規および変更されたファイルを保存すること、回復可能な同期の失敗を再試行すること、評価の終了前に最後の同期を完了させることです。オブジェクトストレージとの直接転送とファイルの一括記録により、そのコンテキストを保持するためのオーバーヘッドを減らしています。スキャンプロファイルへの展開は段階的に進めています。これは、前述の知識の編集やオプションのTicket Agentのメモリと並ぶ、メモリの基盤に関する継続中の取り組みです。
近日公開：Active DirectoryとRASP
内部ネットワークの診断は、多くの場合、ドメインアカウントと「このIDは攻撃者をどこまで連れて行けるのか」という問いから始まります。当社はそのワークフローに向けて、Active Directoryのテストを準備しています。Kerberosと証明書サービスに関する推論、権限と信頼関係の分析、マシン間の経路の計画です。専用のADツールや、アカウントロックアウトを考慮したパスワードスプレーの制御にも取り組んでいます。近日公開とは、このテストの体験を指すものです。これらの基盤となるエンジニアリング上の変更は、ワークフロー全体が現時点で一般提供されていることを意味するものではありません。
また、モバイルアプリケーション向けの実行時アプリケーション自己保護（RASP）も構築しており、セキュリティを評価から、アプリの実行中の保護にまで広げます。この取り組みは、アプリのハードニング、実行時のチェック、保護シグナルの可視化を一つにまとめるものです。エンドツーエンドの保護のワークフローは近日公開予定で、現在も開発中です。
既存の問題については、Ostorlabでその検出結果のVerify Fixから始めてください。トリアージがたびたび滞るのであれば、少数のチケットを対象にTicket Agentを設定し、ルールの対象を広げる前にその出力を確認してください。
