一份渗透测试报告，渗透客户拿到手里最先翻的测试不是漏洞列表，而是报告风险等级那页。你写了30个漏洞，渗透标了8个高危，测试客户看完只说一句“这几个高危到底会不会让我被黑？报告”——报告就失败了。问题不在技术，渗透在表达。测试

我见过太多报告把“高危”当结论用。报告SQL注入是渗透高危，但一个需要登录后台才能触发的测试SQL注入，和一个前台搜索框就能打的报告SQL注入，风险完全不同。渗透前者可能只是测试中危，后者才是报告真正的高危。CVSS评分给的是基础分，不结合业务场景直接抄，客户会觉得你在吓唬他。

先搞清楚报告给谁看

技术负责人要看复现步骤和Payload，运维要看修复命令，老板只看两样：哪些业务受影响，要花多少人天修。同一份报告要同时服务这三类人，就得分层写。我的习惯是把执行摘要控制在两页以内，用业务语言描述风险，比如“攻击者可绕过登录直接读取用户订单数据”，而不是“存在未授权访问漏洞”。

技术细节放附录。每个漏洞写清楚：请求包、响应包、复现条件、影响范围、修复建议。修复建议别只写“过滤特殊字符”，要给出具体方案——参数化查询、白名单校验、WAF规则，最好附上代码示例。客户的安全工程师会感谢你。

漏洞描述要带证据链

“存在XSS漏洞”这种写法等于没写。要写：在用户昵称字段输入<img src=x onerror=alert(1)>，保存后访问个人主页触发弹窗。截图要带URL和时间戳。Burp的请求响应截图比文字描述管用十倍。

有个细节容易被忽略：测试时间。报告里要写清楚测试窗口期，比如“2024年3月10日 02:00-06:00”。客户运维看到这个时间段，才知道哪些告警是测试流量，不会半夜被叫起来应急。

风险定级别自嗨

我见过一份报告把“服务器开放了22端口”标成中危。SSH暴露在公网确实有风险，但如果客户做了密钥认证+fail2ban，实际风险很低。定级要参考三个维度：利用难度、影响范围、业务重要性。内网测试时发现的核心数据库弱口令，比外网一个反射型XSS严重得多。

客户内部通常有定级标准。没有的话，用CVSS 3.1的向量字符串，但要在报告里解释每个参数为什么这么打。比如AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，得说明为什么PR是N——因为漏洞在登录前触发。

修复建议要可落地

“建议升级组件”这种话等于没说。要写：当前版本Struts 2.3.15，存在S2-045远程代码执行，升级到2.5.30以上，或者临时删除Content-Type头中的恶意OGNL表达式。给出版本号和具体操作，运维才能直接执行。

有些漏洞修不了，比如业务逻辑缺陷需要改架构。这时候要给出缓解措施：加验证码、限制频率、增加二次确认。报告里单独列一个“无法立即修复的风险”章节，客户的安全负责人拿这个去跟业务方沟通，比你直接写“高危”有用。

报告结构别套模板

我自己的模板分五块：执行摘要、测试范围与方法、风险统计、漏洞详情、附录。执行摘要放最前面，但最后写。漏洞详情按风险等级降序排，同等级的按业务模块分组。附录放工具列表、测试账号、原始数据包。

有个客户跟我说过，他看报告先翻附录的测试账号列表，确认我们没碰生产数据。这个细节决定了报告的可信度。测试前签的授权书、测试中用的账号、测试后清理的痕迹，都要在报告里体现。渗透测试是授权攻击，报告就是你的行动记录。

最后说个实在的：报告写完自己读一遍，把“可能存在”“建议关注”这种词全删掉。渗透测试报告不是学术论文，是给客户做决策用的。每个结论都要有证据，每个建议都要能执行。做不到这两点，报告写得再漂亮也是废纸。