技能介绍

一个老问题：挖到了，但没写明白

渗透测试最常见的失败不是没找到漏洞，而是找到之后报告没写清楚。CVSS 打了 9.0 的发现淹没在工具输出截图里，复现步骤缺失，客户开发团队无从下手——这样的发现等于白做。报告是客户付费购买的唯一交付物，也是审计读、开发修的唯一依据，需要和利用漏洞本身同等的严谨。

这套方法论怎么运转

核心是五步工作流：利用时实时记录证据（UTC 时间戳、源 IP、目标、动作、结果、提取数据的哈希），每个发现单独一个编号文件趁上下文新鲜立即起草，所有发现评分完成后再写执行摘要，接着两遍审查——先查技术准确性，再以 CISO 视角审叙事，最后移交时附带复测计划和供客户追踪系统导入的 JSON/CSV 索引。

几条关键纪律：

执行摘要只给决策者看：一页以内，用业务语言写影响（客户数据、合规暴露、运营中断、财务损失），避开 payload、RCE、XSS 这类术语——CISO 需要的是“攻击者可以在服务器上运行任意命令”，不是“通过反序列化 gadget chain 实现 RCE”。
CVSS 是地板不是天花板：先诚实打分，再用 Business Impact Adjustment 段落论证业务上下文为何抬高上报严重性——客服面板里处理 PII 的认证用户 XSS，可能比无认证的内部 SSRF 更危险。
证据链不留瑕疵：截图脱敏（凭据替换为占位符、PII 哈希、用 exiftool -all= 剥离 EXIF、裁掉浏览器标签页泄漏），证据存于 LUKS/FileVault/BitLocker 加密卷，按客户约定在交付后 30–90 天销毁。
范围、限制、假设三段分开写：Scope 是测了什么，Limitations 是什么东西挡住了（仅从互联网测试、未含源码审计），Assumptions 是环境假设（staging 镜像 production）。
交付物从单一 Markdown 源生成：用 Pandoc 导出 PDF/DOCX，静态站点生成 HTML，JSON/CSV 供 DefectDojo、ServiceNow、Jira 导入——不要手工维护多份平行格式。

适用边界与注意点

这套方法面向正式的渗透测试交付物（甲方付费、审计留档），不适合 bug bounty 场景——赏金 triage 人员时间紧张且多疑，要求 80 字符内写清漏洞类型、端点与影响，用单个 curl 命令复现并对比预期与实际响应，好报告两分钟读完、五分钟复现。另一个常见陷阱是过度 CVSS：每个发现都打 9.0，客户就失去了判断真实 critical 的能力。最后，复测不是可选项——每个修复发现都要附上验证请求与响应，没有证据的 fixed 只是传闻。