漏洞报告怎么写？从流水账到风险决策材料的五步法

承认吧，你在众测平台或接单群里交出去的漏洞报告，大概率就是一份“测试过程复述稿”——第一步访问了哪个页面、第二步改了哪个参数、第三步看到了什么报错，最后贴一句“建议使用参数化查询”。这种报告，平台审核不会打回，甲方也不会说“写得不对”，但下一次再想约你测试，就没下文了。

我早几年也是这样。直到有一次我交付完报告，甲方技术对接人在电话里委婉提了一句：“兄弟，测试做得很细，但我们领导看完报告后问了一句，这个漏洞到底会不会导致用户数据泄露？”那一刻我才意识到，漏洞报告不是写给“看得懂的人”看的工单，而是写给“决定要不要批预算的人”看的决策材料。甲方愿不愿意为一份报告“加钱”，本质取决于你能不能让他拿着你的报告，顺利说服他的上级立项整改。这不是文字功底的问题，是报告结构的问题。

这篇内容我分五个步骤、一个完整模板、一个真实案例改写对比来说清楚，怎么把“流水账”改成一页纸就能让人看懂危害、看懂优先级、看懂怎么验收的报告。适合正在做众测兼职、接安全服务外包的渗透测试人员，也适合SRC挖洞想提升漏洞提交通过率的同学。

1. 先搞懂甲方为什么不想为“流水账”买单

很多兼职测试员有个惯性思维：漏洞是“测”出来的，报告只是附带的证据记录。所以写报告时默认读者是另一个渗透测试工程师，恨不得把每一个试过的payload和临时想到的思路全写进去。但真实场景里，收到你报告的人通常有三个——安全工程师、技术负责人、信息化分管领导。三个人关心的事完全不一样，而决定“这份活值多少钱”的，往往是那个最不懂技术细节、但掌握预算支配权的人。

当然，这里不是让你忽略安全工程师的需求。真正高价值的报告要“双层可读”：第一层是给管理者看的摘要和风险判断，30秒能看懂“出了什么事、多严重、要不要马上处理”；第二层是给技术执行者看的完整证据和修复指引，拿到手就能复现、能派工、能验收。流水账报告最大的问题，就是把这两层混在一起，让每个人都得在几百行测试记录里自己找重点。

另一个被忽略的点是“报告的时间成本”。甲方安全工程师手里同时压着很多事，你的报告如果是规范的、结论清晰的，他可以快速抄进内部工单系统，直接用作预算申请和排期依据；如果是一堆零散截图加文字堆砌，他至少要花半小时帮你整理重写。整理一次两次可以，次次如此，下次合作机会自然就给别人了。

所以，“加钱”的本质逻辑是这样的：你的测试发现是1，报告能不能把这个1放大成3或5，取决于它能不能同时回答三个问题——这个漏洞最坏会造成什么业务影响？它现在处于什么风险等级、该按什么优先级处理？按你们的方法整改后，怎么验证确实修好了？一份报告只要同时满足这三点，就已经不能叫“漏洞描述”了，而是叫“风险决策支持材料”。

2. 第1~2步：锁定报告读者，把“测试日志”改成“风险叙事”

五步法的前两步，解决的是“写给谁”和“怎么组织证据”的问题，也是从流水账走向决策材料的关键转折。

2.1 第一步：动笔前先确认报告最终落到谁手里

这个信息的获取成本极低，但很多人不做。接单时直接问对接人一句话：“这份报告需要支持你们内部立项整改吗？除了你之外，还会有管理层或业务方看吗？”就够了。得到的答案直接决定你的报告怎么写。

如果对接人说“我自己看就行，流程需要”，那你可以适当精简管理层摘要部分，但建议还是保留一页执行摘要。因为你不知道这份报告之后会被转给谁。我吃过一次亏：某个授权评估项目的对接人是安全负责人，我按“技术纯享版”交付，结果他转给运维和研发Leader时，对方反馈“看不懂危害有多大”，最后整改优先级被压得很低。之后我所有报告默认带执行摘要，宁可对方觉得多余，也不能让他没法往上传。

同时要注意，接单场景中的“读者”不止甲方内部人员。如果走众测平台交付，中间还有平台审核。平台审核员的续期、定级标准通常介于“技术细节”和“业务危害”之间——既要求当事技术证据链完整，也要求说明通用影响范围。报告如果只有业务影响没有技术细节，平台评审不好通过；只有技术细节没有业务危害，甲方可能压价。前两步把技术细节和业务影响同时做足，在平台上同样受