pentest-reporting

渗透测试报告（REPORT 阶段——让工作产生价值的最后一步）

概述

无人修复的漏洞谈不上安全。本阶段将原始发现转化为一份工程师可以据此采取行动、领导者可以据此确定优先级的报告：严重程度一致、复现步骤清晰、影响描述诚实、修复方案具体，并跟踪问题直至关闭。

核心原则： 同时面向两类读者——需要了解风险和优先级的高管，以及需要准确复现和修复步骤的工程师。

优质报告的结构

1. 执行摘要——用通俗语言说明风险态势、排名前 3–5 的风险以及总体结论。避免使用术语。
2. 范围与方法——测试内容、环境、日期以及不在范围内的内容。
3. 发现——每项发现单独列出（见模板），并按严重程度排序。
4. 修复路线图——按优先级排列的修复清单，并估算所需工作量。
5. 复测结果——修复后每项发现的状态（Open / Fixed / Risk-accepted）。
6. 附录——工具、原始证据、参考资料。

发现模板（每个问题都使用）

Title:        <Concise, e.g. "IDOR in /api/invoices exposes other users' billing">
Severity:     Critical | High | Medium | Low | Info   (CVSS x.x — vector)
Affected:     <endpoint / file:line / component>
Summary:      <1–2 sentences: what's wrong and why it matters>
Reproduction: <numbered, copy-pasteable steps / exact request>
Evidence:     <response excerpt / screenshot, real data redacted>
Impact:       <business consequence: data exposed, money, accounts, scope>
Remediation:  <specific fix, link to security-hardening pattern>
Status:       Open | Fixed (retested <date>) | Risk-accepted

严重程度与 CVSS

采用一致的评分方式，确保优先级有理有据。关于 CVSS v3.1 指标、基础分速查表和完整报告框架，请参阅 references/cvss-and-template.md。

严重程度	大致 CVSS	含义
Critical	9.0–10.0	立即修复——完全失陷 / 大规模数据泄露 / 未经身份验证的 RCE
High	7.0–8.9	本周期内修复——ATO、敏感数据、权限提升
Medium	4.0–6.9	纳入计划——需要特定条件或影响有限
Low	0.1–3.9	列入待办——影响轻微 / 纵深防御
Info	0.0	记录——最佳实践建议，无直接风险

根据业务背景调整：在支付链路上的“Medium”对你而言可能是“High”。

编写规则

• 可复现，否则就等于没发生——提供开发者可以直接粘贴并重新运行的步骤。
• 用业务语言描述影响——例如“任何用户都能读取所有发票”，而不是“缺少授权检查”。
• 每项发现只给出一个修复方案——指出确切的 security-hardening 模式。
• 不渲染恐慌，不写废话——严重程度要准确；夸大其词会失去信任，轻描淡写则会被忽视。
• 对证据中的真实数据进行脱敏。

复测与关闭

对于每项已修复的发现：重新运行原始 PoC，记录通过/失败结果和日期，并设置状态。只有所有 High+ 级别的发现都已标记为 Fixed，或由负责人明确标记为 Risk-accepted，报告才算完成。

交接

发现来自所有 FIND/EXPLOIT 技能；修复由 security-hardening 负责；本技能负责整理并跟踪问题直至关闭（将每项 High+ 级别的发现复测通过后再标记为已修复）。

常见错误

• 把扫描器输出直接当作“报告”——先进行分类、去重和验证。
• 凭感觉判断严重程度——结合 CVSS 和业务背景，确保优先级经得起推敲。
• 编写只有自己才能遵循的复现步骤——要让陌生人也能照着操作。
• 不做复测——不重新运行漏洞利用就声称“已修复”，只是猜测。