Strix Quick 扫描模式：时间受限下的高危漏洞快速评估方法论与实现解析

本篇围绕 Strix 仓库中的 Quick 扫描模式技能文档（strix/skills/scan_modes/quick.md）展开，讲解这套"限时（time-boxed）优先广度"的渗透测试方法论：三个阶段（快速定向 → 高危目标 → 最小化验证）如何运作、哪些高影响漏洞被优先测试、哪些检查被明确跳过，以及该模式如何通过 Strix 的技能注入机制在 --scan-mode quick 时自动加载到 Agent 系统提示中。读完本文，你可以理解 Quick 模式与 Standard/Deep 模式的分工边界，并知道如何在 CI/CD 中用它做分钟级的高危漏洞冒烟检查。

Quick 模式是什么：一份注入 Agent 的方法论技能

Quick 模式的定义文件位于 quick.md，YAML frontmatter 声明了它的元数据：

---
name: quick
description: Time-boxed rapid assessment targeting high-impact vulnerabilities
---

正文开宗明义："Time-boxed assessment focused on high-impact vulnerabilities. Prioritize breadth over depth."（时间受限、聚焦高影响漏洞，广度优先于深度）。

需要强调的是，这类 .md 文件不是给人阅读的普通文档，而是 Strix 的 Skill（技能）——一种专门化知识包。按照 Skills README 的说明，Agent 创建时可加载最多 5 个与子任务相关的技能，技能内容会被动态注入 Agent 的系统提示，使其在特定漏洞类型、技术栈或测试方法上获得深度专业能力。scan_modes/ 目录下的 quick、standard、deep、diff 四类文件，正是控制"这次扫描用多大深度"的方法论技能。

从 CLI 参数到系统提示：Quick 技能的注入链路

Quick 模式并不是"另一种程序"，而是同一条执行管线上的一个提示词层开关。完整调用链如下：

1. CLI 层：cli_args.py 定义了 -m / --scan-mode 参数，取值为 quick、standard、deep，默认 deep：

   # 快速 CI/CD 检查
   strix --target ./app --scan-mode quick
   

   同一处还定义了 --scope-mode（auto / diff / full）：在 CI/无头运行中，auto 会自动启用 PR 差异作用域，让扫描只覆盖变更文件——这与 Quick 模式"关注近期变更"的思路天然互补。

2. 技能解析层：prompt.py 中的 _resolve_skills() 负责构建每个 Agent 最终加载的技能列表。其顺序规则是：调用方显式请求的技能 → scan_modes/<mode>（恒加载） → 若运行是 diff 作用域则叠加 scan_modes/diff（"diff 作用域是叠加在深度模式之上，而非替换它"）→ 恒加载 tooling/agent_browser、tooling/python、analysis/counterevidence、analysis/severity_calibration；根 Agent 额外加载 coordination/root_agent，白盒（有源码）场景额外加载 coordination/source_aware_whitebox、custom/source_aware_sast 等。最后按"保序去重"输出。

3. 模板渲染层：render_system_prompt() 通过 Jinja2 模板 system_prompt.jinja 将解析出的技能正文（经 get_skill 全局函数）与其余上下文一起渲染成最终系统提示。此外，Agent 在运行中若需要临时的精确语法/工作流/载荷指导，还可以调用 load_skill 工具把技能正文作为工具结果拉进对话（单次最多 5 个），而不必永久改动提示。

所以执行 strix --target ./app --scan-mode quick 时，实际上发生的"深度切换"就是：_resolve_skills() 把 scan_modes/quick 而不是 scan_modes/deep 追加进技能列表，Quick 方法论全文随系统提示进入 Agent 的决策上下文。技能加载机制本身可参考 strix/skills/init.py（其中 scan_modes 被归类为内部技能类别）。

Phase 1：快速定向（Rapid Orientation）

Quick 模式的第一阶段要求在最短时间建立对目标的最小可用认知。白盒（有源码）与黑盒（无源码）两条路径的策略截然不同，文档原文要求如下：

白盒（源码可用）

• 聚焦近期变更：git diff、新提交、被修改的文件——这些最可能包含新引入的 bug；
• 先对变更文件跑一次快速静态分诊：先用 semgrep，再做有针对性的 sg（ast-grep）查询；
• 至少执行一遍轻量 AST 结构解析（sg 或 Tree-sitter），保证"结构映射"这一步不被跳过；
• AST 命令必须严格限定在变更路径或高风险路径内，避免对整个仓库做宽泛的模式倾倒（pattern dumps）；
• 在可行范围内，把快速密钥/依赖检查（gitleaks、trufflehog、trivy fs）也限定在变更区域；
• 在变更代码中识别安全敏感模式：鉴权检查、输入处理、数据库查询、文件操作；
• 沿被修改的代码路径追踪用户输入的流向；
• 确认安全控制是否被修改或绕过。

黑盒（无源码）

• 映射认证流程与关键用户流程；
• 识别暴露的端点与入口；
• 跳过深度内容发现——只测当前立即可访问的部分。

对比 standard.md 的第一阶段（完整代码库结构映射、技术栈指纹、全量爬取）就能看出 Quick 模式省掉了什么：它不要求"理解整个应用"，只要求"看懂这次变更/当前可达面"。

Phase 2：高影响目标（High-Impact Targets）

这是 Quick 模式的核心筛选逻辑。文档规定了严格的测试优先级顺序（test in priority order）：

优先级	目标类别	覆盖内容
1	认证绕过（Authentication bypass）	登录缺陷、会话问题、令牌弱点
2	访问控制失效（Broken access control）	IDOR、权限提升、缺失的鉴权
3	远程代码执行（RCE）	命令注入、反序列化、SSTI
4	SQL 注入	认证端点、搜索、过滤器
5	SSRF	URL 参数、Webhook、集成
6	暴露的密钥（Exposed secrets）	硬编码凭据、API Key、配置文件

与"测什么"同样重要的是"不测什么"。Quick 扫描明确跳过以下工作：

• 穷举式子域名枚举；
• 完整目录爆破；
• 低危信息泄露；
• 没有可用 PoC 的理论性问题。

这一取舍正是"时间受限"的方法论体现：预算有限时，资源全部投向能直接产生高危结论的攻击面，把 Deep 模式才需要的长尾枚举留给专项审计。

Phase 3：验证（Validation）与漏洞链（Chaining）

验证三原则（Phase 3 原文要求）：

• 用最小化的 proof-of-concept 确认可利用性；
• 证明真实影响，而非理论风险；
• 发现即报告（report findings immediately as discovered），不攒到最后。

链式利用（Chaining） 是 Quick 模式中容易被低估的一条规则：当找到一个强原语（strong primitive）——认证弱点、注入点、内网访问通道——时应立即尝试一次高影响跳转（one high-impact pivot），以展示最大严重度。文档的表述很直白："Don't stop at a low-context 'maybe'—turn it into a concrete exploit sequence that reaches privileged action or sensitive data."（不要停留在低语境的"也许"上，要把它变成一条能触达特权操作或敏感数据的具体利用序列。）

注意 Quick 模式只要求"一次"高影响跳转，而 deep.md 要求持续链式利用直到最大权限/最大数据暴露，standard.md 则要求文档化完整攻击路径——三者对"链"的深度要求逐级递增，这是区分三个模式的关键指标之一。

操作准则与"Bug Bounty 心态"

文档的 Operational Guidelines 给出了 Quick 模式下的工具使用纪律：

• 浏览器工具：用于关键流程的快速手工测试；
• 终端：跑目标明确、带快速预设的扫描，例如 nuclei 只启用 critical/high 模板；
• 代理（proxy）：检查关键端点的流量；
• 跳过广泛模糊测试——只用目标明确的 payload；
• 子 Agent 只用于高优先级任务的并行化，不为并行而并行。

Mindset 一节则给出角色定义："Think like a time-boxed bug bounty hunter going for quick wins."——像一个限时赏金猎人那样追求快赢：关键区域广度优先；看起来可利用就快速验证然后继续；某个攻击向量迟迟没有产出就立刻转向（pivot），绝不恋战。

Quick 在三种模式中的定位与选型

官方使用文档 scan-modes.mdx 给出了三模式的官方定位与耗时预期：

模式	命令	官方定位	预期耗时
Quick	strix --target ./app --scan-mode quick	针对明显漏洞的快速检查	分钟级
Standard	strix --target ./app --scan-mode standard	例行的平衡测试	30 分钟 ~ 1 小时
Deep（默认）	strix --target ./app --scan-mode deep	彻底渗透测试，含边界情况、漏洞链、复杂攻击路径	1 ~ 4 小时

选型建议（引自同一文档）：

场景	推荐模式
每个 PR	Quick
每周扫描	Standard
重大版本发布前	Deep
Bug bounty 狩猎	Deep

此外还有一个维度值得注意：--scope-mode diff（或 CI 下的 auto）触发的 diff 技能 与 Quick 是叠加关系而非替代关系——prompt.py 的注释明确写着 "diff scope overlays the depth mode rather than replacing it"。也就是说，Quick 模式叠加 diff 作用域后，Agent 既执行"限时高危优先"的方法论，又遵守 diff 技能中"只报本次变更引入/新可达/新削弱的问题、锚定变更行、按变更组件记录覆盖率"的评审边界。对 CI 场景来说，--scan-mode quick --scope-mode diff（或依赖 auto 自动启用）就是"分钟级 PR 高危门禁"的推荐组合。

从 TUI 侧的实现也能佐证三模式的对称性：projection.py 中定义了 SCAN_MODES = ("quick", "standard", "deep")，model_test.go 的测试用例即以 ScanMode: "quick" 覆盖该状态，说明 Quick 与另外两种模式在运行时状态机中是完全对等的一等公民。

小结：Quick 模式的本质是把"预算纪律"写进方法论

Quick 模式的价值不在于它独有的攻击技术——semgrep、nuclei critical 模板、IDOR、SQLi 这些手段在 Standard/Deep 中同样存在——而在于它为同一套工具链施加了一套预算纪律：

1. 定向阶段只看变更与可达面，白盒场景把静态分诊、AST 解析、密钥检查全部收窄到 diff 区域；
2. 测试阶段用固定优先级（认证 → 访问控制 → RCE → SQLi → SSRF → 密钥）和明确的跳过清单排除长尾工作；
3. 验证阶段要求最小 PoC、真实影响、即时报告，并以"一次高影响 pivot"为链式利用的上限；
4. 工具使用有纪律：nuclei 只跑 critical/high、不广泛 fuzzing、子 Agent 只并行高优任务。

由于这套方法论以 Skill 形式存在、由 _resolve_skills() 按 --scan-mode 参数自动注入系统提示，它对整个 Agent 团队（根 Agent 与所有子 Agent）统一生效；而 load_skill 工具又保证了 Agent 在需要临时查阅特定技术指南时可以按需拉取，无需重建提示。这套"参数 → 技能解析 → 提示渲染"的机制，是 Strix 用纯提示词工程在同一代码库上切出三档扫描深度的核心实现。