Shannon 渗透测试覆盖范围解析：WST 检查清单、五类可利用漏洞与 Proof-by-Exploitation 模型

Shannon（Keygraph 出品的 AI 自动化渗透测试工具）对 Web 应用与 API 的覆盖能力并非“什么都扫”，而是围绕一组经过刻意筛选的可利用漏洞类型展开。本文基于仓库根目录的 COVERAGE.md 及其配套文档 docs/coverage-roadmap.md，完整梳理 Shannon 当前覆盖的 WSTG（OWASP Web Security Testing Guide）测试项、明确不覆盖的边界，并结合仓库源码说明这一覆盖范围是如何在配置、提示词与流水线层面真实落地的。读完本文，你可以准确评估 Shannon 对一次渗透测试的能力边界，并知道如何用 vuln_classes 配置精确裁剪测试范围。

覆盖哲学：只报“能利用起来的”漏洞

理解 Shannon 的覆盖清单，先要理解它的设计前提。COVERAGE.md 开篇即定义了 WST 检查清单的定位：它系统性列出 Web 应用安全测试的各个维度——信息收集、认证、会话管理、输入验证、错误处理等。但 Shannon 的原则是透明：只有“被设计为能稳定捕获”的漏洞才被打勾，而不是把动态检测偶然触及的领域算作正式覆盖。原文明确写道：

Our coverage is strategically focused on the WST controls that are applicable to today's Web App technology stacks.（我们的覆盖战略性地聚焦于适用于当代 Web 应用技术栈的 WST 控制项。）

docs/coverage-roadmap.md 进一步阐明了“报告哲学”（Reporting Philosophy）：Shannon 遵循 proof-by-exploitation（利用即证明） 模型——凡是无法用一个可运行的 PoC 演示的发现，不会进入最终报告。这既减少了推测性噪音，也意味着 Shannon 不追求报告一个仓库里的所有安全问题：依赖项、策略、配置与广谱静态分析类发现被排除在核心工作流之外。

这一哲学直接决定了覆盖清单的形态：清单里的每一类漏洞，最终都对应一个会真实发起攻击的 Agent，而不只是关键词匹配。

当前覆盖：五类可利用漏洞

COVERAGE.md 列出的 Current Coverage（当前覆盖）为五类可利用（exploitable）漏洞：

• Broken Authentication & Authorization（认证与授权失效）
• SQL Injection（SQL 注入）
• Command Injection（命令注入）
• Cross-Site Scripting（XSS，跨站脚本）
• Server-Side Request Forgery（SSRF，服务端请求伪造）

注意这里刻意合并与细化的粒度：认证和授权被并为一项对外表述，而在 Shannon 内部它们是两条独立的分析/利用管线；“Injection”一类内部则同时覆盖 SQLi、命令注入、LFI/RFI、SSTI、路径穿越与不安全反序列化。

源码佐证：覆盖范围是由代码常量与配置共同锁定的

这五类覆盖不是文档口号，而是在 worker 端被硬性编码的：

1. 常量定义：apps/worker/src/types/config.ts 中定义了全量漏洞类常量：

   export const ALL_VULN_CLASSES: readonly VulnClass[] = ['injection', 'xss', 'auth', 'authz', 'ssrf'];
   

2. 配置模式：apps/worker/configs/config-schema.json 中 vuln_classes 字段的枚举恰好只有这五个值，并说明：“当省略时，五类全部运行；当设置时，仅运行所列类别，对应的 vuln+exploit agent 与报告章节才被包含。”

3. 默认行为：apps/worker/src/config-parser.ts 的 distributeConfig 函数中，未配置时默认回落到 ALL_VULN_CLASSES，即跑满五类。

4. 提示词层面：每个专项分析 prompt 都在注入 {{VULN_CLASSES_TESTED}} 占位符（如 apps/worker/prompts/recon.txt 第 24 行：“Downstream vulnerability analysis will cover these classes: {{VULN_CLASSES_TESTED}}. Map only what supports these classes.”），apps/worker/src/services/prompt-manager.ts 在未配置时填充默认值 injection, xss, auth, authz, ssrf。

5. 管线层面：每个漏洞类都有成对的 prompt 文件——分析阶段（vuln-injection.txt、vuln-xss.txt、vuln-auth.txt、vuln-authz.txt、vuln-ssrf.txt）与利用阶段（exploit-injection.txt 等），位于 apps/worker/prompts/ 目录，覆盖 WSTG 清单中标 ✅ 的注入、XSS、认证、授权、SSRF 各测试项。

换言之，文档宣称的覆盖 = 代码常量的枚举边界 = 提示词与 Agent 的实际数量，三者严格一致。

Shannon 不覆盖什么：与 SAST 的分工边界

COVERAGE.md 用单独一节划定了“不覆盖”边界，这点对正确使用产品至关重要。原文明确：

• 该清单不是全部潜在安全风险的穷举；
• Shannon 不会报告它无法主动利用的问题，例如：
  • 使用了有漏洞的第三方库；
  • 弱加密算法；
  • 不安全的配置。

这类静态分析（static analysis）类发现被明确划归未来的 Keygraph Code Security (SAST) 产品；docs/coverage-roadmap.md 也指出，需要更广泛静态与组织级覆盖的团队应参考 Keygraph 平台。因此，如果你的目标是依赖项漏洞（SCA）、密钥泄露、IaC 或容器扫描，Shannon Open Source 不在正确的位置——这是设计选择，而非缺陷遗漏。

从源码结构看，这一边界还延伸到运行时：注入分析 Agent 的覆盖要求（见 apps/worker/prompts/vuln-injection.txt）聚焦“从网络可达入口到危险 sink 的污点数据流”，对“本地才能执行的脚本、构建工具、CI 脚本”等一律排除（apps/worker/prompts/recon.txt 的 scope_boundaries 一节给出了明确的 In-Scope/Out-of-Scope 定义）。

WST 测试检查清单：逐项状态详解

以下是 COVERAGE.md 中的完整 WSTG 测试清单。✅ 表示 Shannon 设计为能稳定捕获的测试项，未打勾项表示当前不在正式覆盖承诺之内（但动态测试中可能偶然触及）。该表是评估 Shannon 与一次人工渗透测试之间能力差异的最直接依据。

测试 ID	测试名称	状态
WSTG-INFO	信息收集（Information Gathering）
WSTG-INFO-01	搜索引擎发现与信息泄露侦察
WSTG-INFO-02	Web 服务器指纹识别	✅
WSTG-INFO-03	Web 服务器元文件信息泄露审查
WSTG-INFO-04	枚举 Web 服务器上的应用
WSTG-INFO-05	网页内容信息泄露审查
WSTG-INFO-06	识别应用入口点	✅
WSTG-INFO-07	映射应用内执行路径	✅
WSTG-INFO-08	Web 应用框架指纹识别	✅
WSTG-INFO-09	Web 应用指纹识别	✅
WSTG-INFO-10	映射应用架构	✅
WSTG-CONF	配置与部署管理测试
WSTG-CONF-01	网络基础设施配置测试	✅
WSTG-CONF-02	应用平台配置测试
WSTG-CONF-03	敏感信息文件扩展名处理测试
WSTG-CONF-04	旧备份与未引用文件敏感信息审查
WSTG-CONF-05	基础设施与应用管理接口枚举
WSTG-CONF-06	HTTP 方法测试
WSTG-CONF-07	HTTP 严格传输安全（HSTS）测试
WSTG-CONF-08	RIA 跨域策略测试
WSTG-CONF-09	文件权限测试
WSTG-CONF-10	子域名接管测试	✅
WSTG-CONF-11	云存储测试
WSTG-CONF-12	内容安全策略（CSP）测试
WSTG-CONF-13	路径混淆测试
WSTG-CONF-14	其他 HTTP 安全头配置错误测试
WSTG-IDNT	身份管理测试
WSTG-IDNT-01	角色定义测试	✅
WSTG-IDNT-02	用户注册流程测试	✅
WSTG-IDNT-03	账户置备流程测试	✅
WSTG-IDNT-04	账户枚举与可猜测账户测试	✅
WSTG-IDNT-05	弱用户名策略或未强制执行测试	✅
WSTG-ATHN	认证测试
WSTG-ATHN-01	凭据是否经加密通道传输测试	✅
WSTG-ATHN-02	默认凭据测试	✅
WSTG-ATHN-03	弱锁定机制测试	✅
WSTG-ATHN-04	认证机制绕过测试	✅
WSTG-ATHN-05	弱“记住密码”功能测试
WSTG-ATHN-06	浏览器缓存弱点测试
WSTG-ATHN-07	弱密码策略测试	✅
WSTG-ATHN-08	弱安全问题答案测试	✅
WSTG-ATHN-09	弱密码修改/重置功能测试	✅
WSTG-ATHN-10	替代通道弱认证测试	✅
WSTG-ATHN-11	多因素认证（MFA）测试	✅
WSTG-ATHZ	授权测试
WSTG-ATHZ-01	目录穿越文件包含测试	✅
WSTG-ATHZ-02	授权机制绕过测试	✅
WSTG-ATHZ-03	权限提升测试	✅
WSTG-ATHZ-04	不安全直接对象引用（IDOR）测试	✅
WSTG-ATHZ-05	OAuth 弱点测试	✅
WSTG-SESS	会话管理测试
WSTG-SESS-01	会话管理机制测试	✅
WSTG-SESS-02	Cookie 属性测试	✅
WSTG-SESS-03	会话固定测试	✅
WSTG-SESS-04	暴露的会话变量测试
WSTG-SESS-05	跨站请求伪造（CSRF）测试	✅
WSTG-SESS-06	登出功能测试	✅
WSTG-SESS-07	会话超时测试	✅
WSTG-SESS-08	会话猜测测试
WSTG-SESS-09	会话劫持测试
WSTG-SESS-10	JSON Web Token 测试	✅
WSTG-SESS-11	并发会话测试
WSTG-INPV	输入验证测试
WSTG-INPV-01	反射型 XSS 测试	✅
WSTG-INPV-02	存储型 XSS 测试	✅
WSTG-INPV-03	HTTP 动词篡改测试
WSTG-INPV-04	HTTP 参数污染测试
WSTG-INPV-05	SQL 注入测试	✅
WSTG-INPV-06	LDAP 注入测试
WSTG-INPV-07	XML 注入测试
WSTG-INPV-08	SSI 注入测试
WSTG-INPV-09	XPath 注入测试
WSTG-INPV-10	IMAP/SMTP 注入测试
WSTG-INPV-11	代码注入测试	✅
WSTG-INPV-12	命令注入测试	✅
WSTG-INPV-13	格式化字符串注入测试
WSTG-INPV-14	孵化型漏洞测试
WSTG-INPV-15	HTTP 分割/走私测试
WSTG-INPV-16	HTTP 入站请求测试
WSTG-INPV-17	Host 头注入测试
WSTG-INPV-18	服务端模板注入（SSTI）测试	✅
WSTG-INPV-19	服务端请求伪造（SSRF）测试	✅
WSTG-INPV-20	批量赋值（Mass Assignment）测试
WSTG-ERRH	错误处理
WSTG-ERRH-01	错误处理不当测试
WSTG-ERRH-02	堆栈跟踪测试
WSTG-CRYP	密码学
WSTG-CRYP-01	弱传输层安全（TLS）测试	✅
WSTG-CRYP-02	填充预言机（Padding Oracle）测试
WSTG-CRYP-03	未加密通道传输敏感信息测试	✅
WSTG-CRYP-04	弱加密测试
WSTG-BUSLOGIC	业务逻辑测试
WSTG-BUSL-01	业务逻辑数据验证测试
WSTG-BUSL-02	请求伪造能力测试
WSTG-BUSL-03	完整性检查测试
WSTG-BUSL-04	流程时序测试
WSTG-BUSL-05	功能使用次数限制测试
WSTG-BUSL-06	工作流绕过测试
WSTG-BUSL-07	应用误用防御测试
WSTG-BUSL-08	意外文件类型上传测试
WSTG-BUSL-09	恶意文件上传测试
WSTG-BUSL-10	支付功能测试
WSTG-CLIENT	客户端测试
WSTG-CLNT-01	DOM 型 XSS 测试	✅
WSTG-CLNT-02	JavaScript 执行测试	✅
WSTG-CLNT-03	HTML 注入测试	✅
WSTG-CLNT-04	客户端 URL 重定向测试	✅
WSTG-CLNT-05	CSS 注入测试
WSTG-CLNT-06	客户端资源操纵测试
WSTG-CLNT-07	跨源资源共享（CORS）测试
WSTG-CLNT-08	跨站闪现（XSS Flashing）测试
WSTG-CLNT-09	点击劫持测试
WSTG-CLNT-10	WebSocket 测试
WSTG-CLNT-11	Web 消息测试
WSTG-CLNT-12	浏览器存储测试	✅
WSTG-CLNT-13	跨站脚本包含（XSSI）测试	✅
WSTG-CLNT-14	反向标签劫持（Reverse Tabnabbing）测试
WSTG-APIT	API 测试
WSTG-APIT-01	API 侦察	✅
WSTG-APIT-02	API 对象级授权失效（BOLA）测试	✅
WSTG-APIT-99	GraphQL 测试	✅

从清单结构可以看到几个规律：

1. 认证与授权（WSTG-ATHN / WSTG-ATHZ / WSTG-IDNT）覆盖密度最高——身份管理 5 项全勾，认证 9/11 项打勾（仅“记住密码”与浏览器缓存两项未承诺），授权 5 项全勾。这与 apps/worker/prompts/validate-authentication.txt 及 auth/authz 专项 prompt 的存在相互印证。
2. 输入验证类只勾“可利用注入”项：SQLi、代码注入、命令注入、SSTI、SSRF、反射/存储型 XSS 均打勾，而 LDAP/XPath/IMAP/HTTP 走私等未打勾——与“只报可利用漏洞”的哲学一致。
3. 业务逻辑（WSTG-BUSLOGIC）与错误处理（WSTG-ERRH）整段留空：这类问题往往无法用通用 PoC 证明，属于 Shannon 当前边界之外，可结合 docs/coverage-roadmap.md 的“Roadmap Direction”一节关注后续扩展计划。
4. 密码学只勾两项（弱 TLS、未加密传输敏感信息）：弱加密算法（WSTG-CRYP-04）恰是文档“不覆盖”一节点名的静态分析类发现。

覆盖范围在运行时如何生效：配置驱动的管线裁剪

文档承诺的覆盖范围，在 Shannon 中通过配置文件（可选）动态裁剪。以 apps/worker/configs/example-config.yaml 为例，其中注释示例为：

# vuln_classes: [injection, xss, auth, authz, ssrf]

各要素的解析逻辑可在 apps/worker/src/config-parser.ts 中找到：

• vuln_classes：字符串数组，取值限定为 injection | xss | auth | authz | ssrf（schema 中 minItems: 1, maxItems: 5, uniqueItems: true）。省略时默认全部运行；显式设置时只运行所列类别，“它们的 vuln+exploit agent 与报告章节才会被包含”（config-schema.json 的字段描述）。
• exploit：字符串枚举 "true" | "false"，默认 true；设为 false 时只运行分析阶段、不执行真实利用——这直接改变了“proof-by-exploitation”报告的产出能力，使用时需要理解：只做分析拿不到最终可利用性验证。
• report：min_severity（low/medium/high/critical）、min_confidence（low/medium/high）、guidance（自由文本指引，如“丢弃缺少安全头的发现”）、sarif（是否旁路输出 SARIF 2.1.0 日志，要求 exploit=true）——这些是报告侧的过滤旋钮，与覆盖范围形成两层裁剪。
• rules_of_engagement：最多 1000 字符的自由文本指令，会被渲染进每一个 Agent 的提示词。

从提示词装配看（apps/worker/src/services/prompt-manager.ts），vuln_classes 会被展开为 {{VULN_CLASSES_TESTED}} 填入侦察（recon）等提示词，使攻击面映射阶段就只为选中的类别收集情报——例如侦察 Agent 被要求“只映射支撑这些类别的内容”（apps/worker/prompts/recon.txt）。

外部攻击者视角：覆盖清单隐含的作用域过滤

WSTG 清单里打勾的每一项，在 Shannon 的实际执行中还被一层“外部攻击者”作用域过滤。两个共享 prompt 片段说明了这一点：

• apps/worker/prompts/shared/_vuln-scope.txt：“只报告可经由 {{WEB_URL}} 从互联网利用的漏洞。排除需要内网访问、VPN 或服务器直接访问才能利用的发现。”
• apps/worker/prompts/recon.txt 的 <attacker_perspective>：以“无内网、无 VPN、无管理员权限的外部攻击者”视角分析。

以注入分析为例，apps/worker/prompts/vuln-injection.txt 要求每条发现进入利用队列前必须标记 externally_exploitable，并明确规定队列准入标准：“仅包含 externally_exploitable = true 的漏洞”。因此，清单上的 ✅ 项描述的是 Shannon 能稳定捕获的攻击类型，实际一次运行产出的发现仍受目标可达性约束。

五类漏洞的“分析→利用”两段式管线

WSTG 清单与 Shannon 管线的对应关系，可以从 prompt 目录结构直接读出：每个覆盖类别都有一对文件，分别驱动两个阶段。以注入类为例（apps/worker/prompts/）：

1. vuln-injection.txt（分析阶段）：执行“负向注入分析”——不做实弹利用，只做白盒数据流追踪。其方法论要求对每条 source→sink 路径记录：完整变换链、按序的净化器列表、净化后是否再次拼接、sink 的槽位类型（如 SQL-val / SQL-ident / CMD-argument / TEMPLATE-expression）、净化与槽位上下文的匹配判定，并产出一个留待利用阶段使用的 witness_payload（如 SQLi 的 '、命令注入的 ; ls -la、SSTI 的 {{7*7}}）。只有判定为 vulnerable 的路径才写入利用队列；被确认安全的向量也要显式记录（set_safe_vectors），避免重复测试。
2. exploit-injection.txt（利用阶段）：读取分析阶段产出的队列与 injection_analysis_deliverable.md，执行真实 PoC，把“潜在失陷”变成“既成失陷”。

其他类别同理：vuln-xss.txt + exploit-xss.txt、vuln-auth.txt + exploit-auth.txt、vuln-authz.txt + exploit-authz.txt、vuln-ssrf.txt + exploit-ssrf.txt。侦察（recon.txt）阶段还会并行派出 Route Mapper、Authorization Checker、Input Validator、Session Handler、Authorization Architecture 与 Injection Source Tracer 六个子 Agent，把端点清单、输入向量、会话机制与注入源全部固化成下游五个专项 Agent 的输入——这正是 WSTG-INFO-06/07/10（入口点识别、执行路径映射、架构映射）打勾的执行基础。

这一“分析阶段证明可达性 + 利用阶段证明可利用性”的两段式设计，是理解 COVERAGE.md 中“only checked the vulnerabilities we are designed to consistently catch”这句话的最短路径：清单上的每一项，背后都有分析 prompt、利用 prompt、队列 schema 与渲染器四件套支撑。

覆盖之外的验证手段：样例报告作为实证

如果想看这份覆盖清单在真实目标上的产出效果，仓库 sample-reports/ 目录下有三份针对故意脆弱应用的完整报告：

• OWASP Juice Shop：20+ 漏洞，含认证绕过、SQL 注入、IDOR、SSRF；
• c{api}tal API：约 15 个严重/高危 API 发现，含命令注入、认证绕过、批量赋值；
• OWASP crAPI：15+ 严重/高危发现，覆盖 JWT、注入、SSRF 与 API 授权路径。

这些报告可作为“五类覆盖 + 外部攻击者作用域”组合下的产出基线：每条发现都附带可复现的 PoC 步骤，而不会出现仅凭静态模式匹配的推测性告警。

路线图：覆盖将向何处扩展

COVERAGE.md 结尾声明 Shannon 正在积极扩展覆盖范围。配套的 docs/coverage-roadmap.md 则给出两条方向性指引：

1. 计划中的覆盖领域以仓库内规范路线图文档为准（如存在），README 只链接不内嵌详细历史；
2. 对当下就需要更广静态与组织级覆盖的组织，指向 Keygraph 平台（docs/keygraph-platform.md）：该平台在 Shannon 引擎之外补齐了 CPG SAST、带可达性的 SCA、密钥/IaC/容器扫描、发现管理、自动修复与验证等能力。

也就是说，Shannon Open Source 的覆盖策略是“少而精”的五类可利用漏洞 + 可复现 PoC；广谱静态覆盖被有意留给 SAST 产品线，而非塞进渗透测试 Agent 里稀释掉报告质量。

小结：如何把覆盖清单落到一次具体的扫描

把上述信息组合起来，使用 Shannon 时可以得到一张清晰的决策表：

你的需求	是否在 Shannon 覆盖内	依据
SQLi / 命令注入 / 代码注入 / SSTI / LFI 可利用漏洞	✅	COVERAGE.md Current Coverage；vuln-injection.txt 源码级追踪
认证缺陷（默认凭据、MFA、弱密码策略等）	✅	WSTG-ATHN 各项打勾；vuln-auth.txt、validate-authentication.txt
授权缺陷（IDOR、权限提升、OAuth 弱点）	✅	WSTG-ATHZ 全勾；vuln-authz.txt
反射/存储/DOM 型 XSS	✅	WSTG-INPV-01/02、WSTG-CLNT-01 打勾；vuln-xss.txt
SSRF	✅	WSTG-INPV-19；vuln-ssrf.txt
漏洞依赖库、弱加密算法、不安全配置	❌（静态分析类）	COVERAGE.md “What Shannon Does Not Cover”，交由 Keygraph SAST
业务逻辑、错误处理、CSP/安全头	❌（未承诺）	WSTG-BUSLOGIC、WSTG-ERRH、WSTG-CONF 大部分留空
需要内网/VPN 才能触达的漏洞	❌	_vuln-scope.txt 外部攻击者作用域

配合 vuln_classes、exploit、report 三组配置（schema 见 apps/worker/configs/config-schema.json），你可以按目标风险画像精确裁剪这一覆盖范围——而清单上每一个 ✅ 的背后，都是仓库中可逐文件核验的 prompt、队列 schema 与渲染实现。