一份渗透测试报告，渗透最怕写成漏洞清单的测试堆砌。客户拿到手，报告翻两页就扔桌上——这种事我见太多了。模板真正有用的渗透报告，是测试让开发看完知道先修哪个，让老板看完知道风险在哪，报告让运维看完知道怎么复现。模板三拨人各取所需，渗透才算合格。测试
先说结构。报告封面、模板授权书、渗透测试范围、测试风险评级、报告漏洞详情、修复建议，这几块缺一不可。但顺序有讲究。我习惯把“风险概览”放最前面，用一页纸把高危漏洞的数量、影响系统、业务后果讲清楚。别让客户翻到第三十页才看到那个能直接拿服务器权限的RCE。有个做电商的客户，报告交过去三天没动静，后来才知道他们CTO只看了前五页。从那以后，概览页我一定加粗标红，把最要命的那个漏洞截图直接贴上去。
漏洞详情怎么写？很多人喜欢复制Scanner的输出，CVE编号一列，CVSS评分一算，完事。这不行。你得写清楚：这个漏洞在哪个URL、用什么Payload打出来的、返回包长什么样、能读到什么数据。最好附上Burp的请求响应截图，或者curl命令。我遇到过开发说“复现不了”，结果一看报告里只写了“存在SQL注入”，连注入点参数名都没提。后来我养成习惯，每个漏洞必须带三步复现：第一步发什么请求，第二步看什么特征，第三步证明危害。少一步，开发就敢跟你扯皮。
风险评级别只信CVSS。CVSS 7.5的漏洞，如果在一个内网测试环境里，实际风险可能还不如一个CVSS 5.0但暴露在公网的管理后台弱口令。我通常给两个分：技术评分和业务评分。技术评分用CVSS，业务评分看资产重要性、数据敏感度、利用难度。两个分都高的，标红加急；一个高一个低的，标黄；都低的，标绿放附录。客户的技术负责人认CVSS，业务负责人认业务评分，各看各的，不打架。
修复建议要具体到代码行或者配置项。别写“对输入进行过滤”，要写“在UserController.java第87行，对username参数使用PreparedStatement替换字符串拼接”。别写“加强访问控制”，要写“在Nginx配置中，对/admin路径添加allow 10.0.0.0/8; deny all;”。能给出补丁最好，给不出就给出参考链接。我一般会附上OWASP的对应页面和官方修复文档。开发照着改，十分钟搞定，他省事，你也省得被追问。
还有个细节：报告里所有截图必须打码。IP、域名、用户数据、Token，一个都不能漏。去年有个同行把客户生产库的账号密码截图直接放进报告，邮件发出去才发现，连夜打电话让客户删邮件。这种事一次就够毁掉整个项目。我现在的做法是，截图先过一遍马赛克工具，敏感字段用黑色矩形盖住，再贴进报告。麻烦是麻烦，但安全。
最后说交付。PDF是标配，但最好再给一份Markdown或者Word。客户可能要摘录内容进Jira，或者把修复建议贴到Confluence。你给PDF，他复制粘贴格式全乱，骂你一句“不专业”。给个可编辑版本，他改起来顺手，下次还找你。另外，报告里别用“贵公司”“我方”这种词，直接写“客户”“测试方”，读起来干脆。渗透测试是技术活，报告是沟通活。技术再牛，报告写不明白，客户觉得你啥也没干。