Shannon 漏洞覆盖范围与"以利用证伪"的报告哲学：从五类 OWASP 检测目标到 Exploitation 流水线的源码实证

本文以 docs/coverage-roadmap.md 为核心，解析 Shannon（Keygraph 开源的 AI 渗透测试代理）当前覆盖的五类可利用漏洞、其"proof-by-exploitation"（以可复现利用证明为报告门槛）的哲学边界，以及仓库中未覆盖的静态分析类问题归属。读完后，你将能够准确判断 Shannon 能证明哪些漏洞、不能报告哪些问题，并沿着仓库源码定位到漏洞队列、利用决策与报告渲染的完整实现链路。

Shannon 的覆盖定位：只报"可利用且可证明"的发现

docs/coverage-roadmap.md 开篇即给出 Shannon 的核心定位：它专注于能够针对运行中的应用进行验证的可利用发现（exploitable findings that can be validated against a running application）。当前覆盖的漏洞类别共有五类：

• Broken Authentication（失效认证）
• Broken Authorization（失效授权）
• Injection（注入）
• Cross-Site Scripting（跨站脚本）
• Server-Side Request Forgery（服务端请求伪造）

这五类恰好对应 OWASP 中危害最高的动态可利用类别。仓库根目录的 COVERAGE.md 进一步说明了这一覆盖策略的边界：它"刻意聚焦于适用于当今 Web 应用技术栈的 WSTG 控制项"，并且动态检测能力虽然常会延伸到其他领域，但官方只勾选了设计上能够稳定捕获的漏洞类型——这是一种透明的覆盖声明，而非能力暗示。

报告哲学：没有 PoC 就没有报告条目

docs/coverage-roadmap.md 的"Reporting Philosophy"一节给出了 Shannon 区别于传统扫描器的关键原则：

Shannon follows a proof-by-exploitation model. Findings that cannot be demonstrated with a working proof of concept are not included in the final report.

翻译过来即：无法用可工作的 PoC 演示的漏洞，不会进入最终报告。该文档同时诚实地指出了这一模型的取舍——它减少了推测性噪声（speculative noise），但也意味着 Shannon 不追求报告仓库中所有可能的安全问题。依赖漏洞、策略问题、配置问题和广义静态分析发现，都明确位于核心工作流之外。

这一哲学在报告产物中有直接体现。以 sample-reports/shannon-report-juice-shop.md 为例，每个已利用条目（如 INJ-VULN-01 "SQL Injection Authentication Bypass"）都包含：漏洞位置、影响说明、严重级别、可直接复制运行的 curl 利用步骤、以及真实返回的响应（如管理员 JWT token），并附"Proof of Impact"一节说明实际达成的影响。另两份样例报告 shannon-report-capital-api.md 与 shannon-report-crapi.md 覆盖了命令注入、认证绕过、Mass Assignment、JWT 与 API 授权路径的发现，均遵循同一"证据先于结论"的格式。

五类覆盖目标在代码中的落点：提示词文件与 Agent 流水线

文档中的五类漏洞并非抽象声明，它们在 worker 源码中有一一对应的实现锚点。apps/worker/prompts/ 目录下，每一类漏洞都拥有独立的分析提示词与利用提示词成对文件：

覆盖类别	漏洞分析 Agent 提示词	利用 Agent 提示词
Broken Authentication	apps/worker/prompts/vuln-auth.txt	apps/worker/prompts/exploit-auth.txt
Broken Authorization	apps/worker/prompts/vuln-authz.txt	apps/worker/prompts/exploit-authz.txt
Injection	apps/worker/prompts/vuln-injection.txt	apps/worker/prompts/exploit-injection.txt
XSS	apps/worker/prompts/vuln-xss.txt	apps/worker/prompts/exploit-xss.txt
SSRF	apps/worker/prompts/vuln-ssrf.txt	apps/worker/prompts/exploit-ssrf.txt

此外，apps/worker/prompts/pre-recon-code.txt、apps/worker/prompts/recon.txt 负责前置的代码侦察与运行时侦察，apps/worker/prompts/report-executive.txt 负责报告阶段，apps/worker/prompts/validate-authentication.txt 则用于验证登录凭据可用性。

以注入类为例，apps/worker/prompts/vuln-injection.txt 明确定义该 Agent 的职责是"白盒代码分析与数据流追踪"，覆盖 SQLi、命令注入、LFI/RFI、SSTI、路径穿越与反序列化；其成功标准是产出"source-to-sink"（源到汇）追踪，包含路径、净化器、汇点上下文与最小 PoC 载荷。值得注意的是其中一段职责边界声明：

Your Role is Precise: You prove the potential for compromise; the Exploitation phase confirms the realized compromise. Do not cross this boundary.

即分析阶段只证明"潜在可被利用"，利用阶段才确认"实际被利用"——这正是"以利用证明"哲学在多 Agent 分工中的具体切分。

漏洞队列：分析到利用之间的结构化桥梁

从源码结构看，"是否有东西可证明"这一决策由漏洞 Agent 提交的利用队列（exploitation queue）驱动。apps/worker/src/ai/queue-schemas.ts 用 TypeBox 为每类漏洞定义了结构化队列 schema，通过自定义工具 submit_exploitation_queue 捕获。所有队列条目共享一组基础字段：

• ID、vulnerability_type：条目标识；
• externally_exploitable（布尔）：该发现是否可从外部利用；
• confidence：枚举值 high / medium / low，表示"这是真实且可达漏洞"的信心等级；
• code_locations：数组，记录该发现触及的每个代码位置（file + 行号 + role，其中 role 枚举为 sink/source/guard，即汇点、不可信输入入口、缺失或错位防护）。

各类漏洞再附加领域字段，例如注入类包含 source、sink_call、sanitization_observed、witness_payload（见证载荷）等。这些结构化数据随后由 findings renderer 消费，进入最终报告——也就是说，docs/coverage-roadmap.md 中"能证明才报告"的门槛，在数据层就体现为"只有进入队列且被利用阶段确认的条目，才会被报告 Agent 记录"。

apps/worker/src/services/exploitation-checker.ts 中的 ExploitationCheckerService 是这一决策的纯领域逻辑实现：它读取某类漏洞的队列文件并返回"是否应运行利用"的决策（ExploitationDecision），日志会输出"5 个漏洞，进入利用"或"无漏洞，跳过利用"。该文件还包含一条值得注意的工程决策注释：队列校验失败时必须抛错而不是降级为"无漏洞"——因为"把一次失败的评估洗白成干净的类别"（Laundering a failure into a 'no vulnerabilities' decision would render an un-assessed class as clean）会违背报告哲学。队列的解析与校验逻辑位于 apps/worker/src/services/queue-validation.ts，其中定义了 VulnType（injection、xss、auth、ssrf、authz 五值）——与文档列出的五类覆盖一一对应。

Shannon 不覆盖什么：静态分析与组织级覆盖的边界

docs/coverage-roadmap.md 明确指出，依赖、策略、配置与广义静态分析发现位于 Shannon 核心工作流之外。COVERAGE.md 给出了同一边界的更具体表述：Shannon 不报告其无法主动利用的问题，例如：

• 易受攻击的第三方库（依赖漏洞）；
• 弱加密算法；
• 不安全配置。

这些静态分析类发现被定位为其 Keygraph Code Security (SAST) 产品线的范畴，即 docs/keygraph-platform.md 所描述的 Keygraph 平台能力（CPG SAST、带可达性分析的 SCA、密钥扫描、IaC 与容器扫描等）。

WSTG 清单中的已验证勾选：覆盖的精确边界

COVERAGE.md 提供了一张对齐 OWASP WSTG（Web Security Testing Guide）的完整测试清单，其中仅勾选"产品能够一致、可靠地处理"的项。将已勾选（✅）项按类别汇总，可得到 Shannon 覆盖面的精确画像：

WSTG 类别	已勾选项（✅）
WSTG-INFO 信息收集	指纹识别 Web 服务器（02）、识别应用入口点（06）、映射应用内执行路径（07）、指纹识别框架（08）、指纹识别应用（09）、映射应用架构（10）
WSTG-CONF 配置与部署管理	网络基础设施配置测试（01）、子域名接管测试（10）
WSTG-IDNT 身份管理	角色定义（01）、注册流程（02）、账户配置（03）、账户枚举与可猜测账户（04）、弱用户名策略（05）——全部 5 项
WSTG-ATHN 认证	凭据加密传输（01）、默认凭据（02）、弱锁定机制（03）、绕过认证方案（04）、弱密码策略（07）、弱安全问题（08）、弱密码修改/重置（09）、替代通道弱认证（10）、MFA 测试（11）
WSTG-ATHZ 授权	目录遍历文件包含（01）、绕过授权方案（02）、权限提升（03）、IDOR（04）、OAuth 弱点（05）——全部 5 项
WSTG-SESS 会话管理	会话管理方案（01）、Cookie 属性（02）、会话固定（03）、CSRF（05）、登出功能（06）、会话超时（07）、JWT 测试（10）
WSTG-INPV 输入验证	反射型 XSS（01）、存储型 XSS（02）、SQL 注入（05）、代码注入（11）、命令注入（12）、SSTI（18）、SSRF（19）
WSTG-ERRH 错误处理	无
WSTG-CRYP 密码学	弱 TLS（01）、未加密通道传输敏感信息（03）
WSTG-BUSLOGIC 业务逻辑	无
WSTG-CLIENT 客户端	DOM 型 XSS（01）、JavaScript 执行（02）、HTML 注入（03）、客户端 URL 重定向（04）、浏览器存储（12）、跨站脚本包含（13）
WSTG-APIT API 测试	API 侦察（01）、API 对象级授权失效（02）、GraphQL（99）

这张清单印证了 docs/coverage-roadmap.md 的声明：覆盖是"战略性聚焦"的——授权与身份管理类别近乎全覆盖，输入验证类别只勾选了 Shannon 五类目标中可利用的那几项（SQLi、代码/命令注入、SSTI、SSRF、XSS），而错误处理与业务逻辑类别目前完全未勾选，与"不报告无法主动利用的问题"的哲学严格自洽。

Roadmap 方向与覆盖演进如何跟踪

docs/coverage-roadmap.md 的"Roadmap Direction"一节确立了仓库的文档组织约定：计划中的覆盖领域应继续存放在仓库的规范 roadmap 文档中（若存在），README 应链接到该文档，而不是内联承载详细的 roadmap 历史。当前仓库中承载覆盖与路线图职责的文档即根目录 COVERAGE.md，而 README.md 的 Documentation 表格将 docs/coverage-roadmap.md 标注为"Current vulnerability coverage and planned work"（当前漏洞覆盖与计划工作）的入口。

对使用者的实际含义是：判断 Shannon 能否证明某类漏洞时，应依次核对三处仓库证据——

1. docs/coverage-roadmap.md 的五类覆盖清单与报告哲学（权威声明）；
2. COVERAGE.md 的 WSTG 勾选清单（按测试项的精确边界）；
3. apps/worker/prompts/ 下的 vuln-*.txt / exploit-*.txt 成对提示词（实现级证据——新类别出现时必然先于此落地）。

对于现在就需要更广静态与组织级覆盖（SAST、SCA、密钥、IaC、容器扫描、发现管理与修复闭环）的组织，docs/coverage-roadmap.md 指向 docs/keygraph-platform.md：Keygraph 平台以增强版 Shannon 为利用引擎，叠加静态解析与发现生命周期管理，其核心差异点之一是"静态-动态关联"——静态发现（如未净化输入流入 SQL 查询）会交由利用 Agent 对运行中的应用实测，并在确认后回溯到精确源码位置。

小结：边界清晰即产品能力

Shannon 的覆盖文档做了一件多数安全工具文档不做的事：不仅列出"能测什么"，同时明确"不报什么"与"为什么"。五类可利用漏洞、以 PoC 为门槛的报告哲学、WSTG 清单中的选择性勾选、以及指向 Keygraph 平台的静态覆盖出口，共同构成一个自洽的覆盖声明。从 queue-schemas.ts 的结构化漏洞队列，到 exploitation-checker.ts 中"评估失败不得洗白为干净"的防御性决策，再到样例报告中可复现的 curl 利用步骤，"证明先于报告"在数据流、控制流与产物三个层面都能找到源码级证据。