一份渗透测试报告，渗透最核心的测试价值在于“可复现”。如果开发团队拿着你的报告包括报告，无法按照你写的内容步骤重新打出那个漏洞，这份报告基本就是渗透废纸。我见过太多报告，测试漏洞描述写得像散文，报告包括什么“存在潜在风险”“可能被利用”，内容全是渗透废话。真正有用的测试报告，第一页就得让修复的报告包括人知道：哪个IP、哪个端口、内容哪个参数、渗透发什么包、测试返回什么结果。报告包括

先讲清楚测试范围。这不是客套话，是法律边界。客户给了三个域名，你顺手把同IP下的其他站点也扫了，哪怕只跑了个目录扫描，都算越界。报告里必须写明：测试目标清单、测试时间窗口、源IP地址、是否包含社工、是否包含内网横向。我习惯在范围部分加一句“本次测试未涉及以下系统”，把边界划死。出过事的人都知道，这句话能救命。

漏洞列表是主体，但排序方式有讲究。按风险等级排？那是给管理层看的。按利用链排？那是给技术团队看的。我通常做两套视图：第一页放一张表，高危、中危、低危、信息泄露各多少，每个漏洞一行，带CVSS评分和受影响资产。后面每个漏洞单独展开，按“利用链顺序”排列——先打哪个点，拿到什么权限，再用这个权限打哪里。这样修复的人能看懂攻击路径，而不是孤立地看一堆漏洞。

单个漏洞的写法，我坚持六要素：漏洞名称、受影响资产、漏洞描述、复现步骤、请求与响应原文、修复建议。复现步骤要细到“在Burp里把这一行替换成payload，点Forward”。请求包和响应包直接贴原始HTTP报文，不要截图，截图没法复制。修复建议别写“加强输入验证”这种空话，要写“在XX文件的XX函数里，对参数id做整型转换后再拼接SQL”。

风险评级这事，很多报告喜欢用“高危、中危、低危”三档，太粗。我一般用CVSS 3.1算分，再结合业务场景调整。一个SQL注入在测试环境是6.5分，在生产环境能拖库就是9.8分。报告里要写清楚评分依据：是能直接拿shell，还是只能读文件？是无需认证，还是需要普通用户权限？这些细节决定了修复的优先级。

修复建议部分，最容易写成废话。我见过一份报告，二十个漏洞的修复建议全是“请及时更新补丁”。这种报告客户看完直接扔垃圾桶。好的修复建议要具体到代码层面，或者至少给出配置示例。比如“在nginx.conf的server块里加add_header X-Frame-Options DENY”，比“建议设置点击劫持防护”有用一百倍。

附录里放什么？很多人放一堆扫描器原始输出，几百页，没人看。我放三样东西：一是测试过程中用到的工具和版本，方便复现；二是所有请求的完整日志，按时间戳排序，万一有争议可以查；三是资产清单，包括域名、IP、端口、服务、中间件版本。这三样东西在后续复测时特别有用。

最后说个细节。报告里所有的时间戳，统一用UTC+8，别一会儿本地时间一会儿UTC。所有IP地址，标注是内网还是公网。所有域名，标注是主站还是子站。这些小事不做，修复的人得花半小时对上下文。渗透测试报告不是文学作品，是施工图纸。图纸画错了，楼就盖歪了。