《渗透报告模板长这样,甲方再也不打回》

上篇说过，报告被打回，跟技术基本没关系。评论区有人问：道理都懂，报告到底长什么样？

这篇直接给答案。我把自己在用的报告结构原样拆开，一共五段。每一段对应甲方谁在看，为什么省不得。

某次授权项目，我挖到一个还不错的问题，自认为报告写得挺清楚。交过去第二天被退回来，意见就一行字：请先说明测试范围。

从那以后我按五段式写报告，再没被因为结构问题退回来过。

第一段，概述与授权范围。写清楚三件事：测了哪些系统、用了什么方式、什么时间段。更重要的是写清楚没测什么。范围外的东西明确标注「未涉及」，这一行字能帮你挡掉大部分扯皮。这是给项目经理看的。

第二段，风险定级。最容易被新人搞砸的一段。直接把 CVSS 分数抄上去，甲方安全部拿一算，分数对不上，整份报告的可信度就废了。正确做法是写两句话：这个漏洞被利用之后，业务会怎么样；利用它需要什么条件。高危不是分数高，是影响大。这是给安全部看的。

第三段，漏洞详情。复现步骤的标准很简单：一个没接触过这个系统的新人，照着你的步骤能一步步敲出来。每一步配一张截图，请求包和响应包都要给。缺响应包的报告，开发没法确认你真的打通了。这是给开发看的。

第四段，修复建议。把百科里的修复方案原样贴上去，开发看了会想打人。版本号要写具体，配置要给示例，升级方案要附兼容性提醒和回归验证项。甲方拿着你的建议能直接安排整改，这份报告才算交完了。

第五段，附录与证据链。截图三原则：打码再放、原图留底、命名对得上漏洞编号。别小看这个，遇到复盘或者对账的时候，规范的证据链能替你说话。

五段归一句话：范围挡扯皮，定级给安全部，复现给开发，建议给整改，证据留给复盘。

这套结构我已经整理成模板了。上篇回复「报告」的那份就是它，还没领的后台回复「报告」自取。另外备了份 HW 告警研判速查表，做蓝队的兄弟用得上，回复「研判」拿走。

下一期写点不一样的：告警研判是怎么判断真假攻击的。扫描器报了个 boolean 盲注，怎么十分钟内定性它是不是误报。关注我，别错过。