内容摘要：去年冬天，我帮一家做跨境电商的朋友看他们刚上线的系统。凌晨两点，他发来一条消息：“数据库里多了个没见过的账号，权限是超级管理员。”我让他立刻查登录日志，发现这个账号是从一个越南IP创建的，而他们公司根

去年冬天，网络我帮一家做跨境电商的安全朋友看他们刚上线的系统。凌晨两点，漏洞他发来一条消息：“数据库里多了个没见过的自评账号，权限是报告超级管理员。”我让他立刻查登录日志，范本发现这个账号是网络从一个越南IP创建的，而他们公司根本没人在越南。安全更麻烦的漏洞是，这个账号在创建后三小时内，自评导出了将近两万条用户订单——包含姓名、报告电话、范本地址和部分支付信息。网络事后复盘，安全漏洞出在一个不起眼的漏洞测试接口上，开发人员图省事，把鉴权逻辑注释掉了，上线时忘了恢复。这就是典型的“自评报告里写‘低风险’，实际却能捅出大篓子”。

写漏洞自评报告，最怕两种心态。一种是“掩耳盗铃”，明明扫描器报了一堆中高危，非说“业务场景不涉及，可忽略”。另一种是“复制粘贴”，把去年的报告改个日期就交差。这两种我都见过，结果都不好。真正有用的自评，得先承认一个事实：没有任何系统是干净的。你写报告的目的不是证明自己安全，而是把真实的风险摊开，让该看到的人看到。

我习惯把漏洞分成三类来写：能直接拿数据的、能间接搞破坏的、以及“现在没事但将来会出事”的。第一类最要命，比如SQL注入、越权访问、未授权文件上传。这类漏洞的自评结论只有两种写法——“已修复”或者“临时缓解，待彻底重构”。别写“计划下季度处理”，攻击者不会等你到下季度。第二类包括XSS、CSRF、逻辑缺陷，它们单独看可能只是弹个窗或者改个参数，但组合起来能撬开第一类的大门。第三类最容易被忽略，比如用了三年没更新的第三方组件、硬编码在代码里的API密钥、日志里明文打印的用户密码。这些东西扫描器不一定报，但你心里得清楚。

具体写的时候，别堆砌CVSS评分。那个分数是给机器看的，给人看的应该是场景。举个例子，一个“中危”的存储型XSS，如果出现在后台管理页面，且只有管理员能访问，那实际风险很低。但如果出现在用户昵称展示区，每个访问个人主页的人都会中招，那它就是高危。我见过一份报告，把“未设置HttpOnly”标成低危，结果攻击者通过XSS偷走管理员Cookie，直接进了后台。所以自评报告里，每个漏洞下面最好加一行“实际利用路径”，哪怕只有一句话。

修复建议别写“建议加强输入验证”这种废话。要写就写具体：哪个文件、哪一行、改成什么。比如“/api/v1/upload 接口，第47行，把 fileType 的白名单从 ['jpg','png'] 改为 ['jpg','png','jpeg']，并增加文件头校验”。如果暂时修不了，就写清楚补偿措施：WAF规则加了哪条、访问频率限制设了多少、监控告警发到哪个群。我甚至见过一个团队，在报告里附上了修复前后的curl命令对比，这种自评才叫到位。

最后说一个反直觉的观点：自评报告里最好保留一两个“已知但未修复”的低危漏洞，并注明原因。比如“该接口仅内网可访问，且已加IP白名单，暂不修复”。这比写“全部修复完毕”更可信。安全是动态的，没人能保证零漏洞。你坦诚地留下一个可控的风险，反而说明你真的在评估，而不是在应付。当然，前提是你真的做了补偿控制，而不是嘴上说说。