一份安全测评报告如果只扔出几十个漏洞列表，安全基本等于废纸。测评我见过某政务系统的报告报告，前二十页全是和漏SQL注入、XSS这些标准项，洞修客户看完直接问：“所以我的复报系统到底能不能上线？”——这才是报告要回答的问题。
测评报告的安全核心不是漏洞数量，是测评风险排序。同一个高危漏洞，报告放在核心交易系统和后台管理模块，和漏影响完全不同。洞修我习惯在报告开头加一段“业务影响速览”：哪些漏洞可被直接利用、复报利用后能拿到什么权限、安全是测评否需要前置条件。比如一个未授权的报告文件上传，如果上传目录可执行脚本，那就是直接拿shell；如果目录做了权限隔离，顶多算个中危。这个判断比CVSS评分更实用。
漏洞描述要具体到可复现。别写“存在SQL注入”，写“在用户查询接口的id参数处，输入1' AND 1=1--返回正常，输入1' AND 1=2--返回空，确认注入点”。修复建议也别只写“参数化查询”，要给出代码示例或者配置片段。很多开发不是不懂原理，是不知道在现有框架里怎么改。
修复报告更麻烦。开发团队经常把“已修复”当成“已正确修复”。我遇到过三次同一个漏洞反复出现——第一次改了一半，第二次只改了测试环境，第三次忘了合并分支。所以修复报告必须包含验证过程：修复前后的请求响应对比、回归测试结果、以及是否引入新问题。最好让开发提供修复commit的hash，方便追溯。
有个细节容易被忽略：修复报告要标注“未修复项及原因”。有些漏洞业务上无法立即改，比如老系统依赖的组件已停止维护。这时候强行要求修复只会导致项目卡死。正确做法是记录风险接受方、补偿措施（比如WAF规则、访问白名单）和复查时间。我见过一份报告把“暂不修复”写成“已忽略”，结果半年后出了事，没人说得清当时谁拍的板。
报告的可读性直接影响修复效率。别用大段文字堆砌，用表格对比修复前后状态，用截图标注漏洞位置，用颜色区分风险等级。但别滥用颜色——满屏红色等于没有重点。我一般只用三种：红（立即修）、黄（计划修）、蓝（可接受）。
最后说个反直觉的观察：很多漏洞修复失败不是因为技术难，是因为报告没送到对的人手里。测评报告给安全团队看，修复报告给开发看，但决策者往往只看到一份摘要。所以我会额外做一页“给管理层的风险说明”：用业务语言描述最坏情况，比如“攻击者可篡改订单金额，预计影响日均流水XX万”。这一页往往比后面五十页技术细节更能推动修复。
报告写完不是终点。两周后我会抽查修复情况，用同样的payload再打一遍。十次里有三次发现“修复不彻底”或“修复后功能异常”。这时候报告才真正闭环——不是交付一份文档，是确认风险被消除或已被明确接受。