去年秋天，网络我帮一家做跨境电商的安全朋友看他们刚上线两个月的后台系统。登录框没验证码，漏洞输错密码也不锁定，自评我拿Burp Suite挂了个字典，报告巴巴不到四十分钟就跑出了三个弱口令账号。道客其中一个还是网络运营主管的，进去直接能看到所有订单和客户手机号。安全朋友当场脸就白了——这套系统上线前，漏洞外包公司给的自评“安全评估报告”写着“整体风险可控”。

这事让我意识到，报告巴巴很多团队嘴里说的道客“安全评估”，跟实际能扛住攻击之间，网络差着十万八千里。安全自评报告不是漏洞写给领导看的免责声明，它得能回答一个具体问题：如果有人现在就来打，我哪里最先破？

先搞清楚“漏洞”到底指什么

不少人把漏洞等同于“代码写得烂”。其实范围宽得多。配置错误算漏洞——比如云存储桶权限设成public；流程缺失也算——比如离职员工账号三个月没注销；甚至物理环境都算，机房没门禁，谁都能进去插U盘。我见过最离谱的一个案例，某公司内网Wiki上直接挂着数据库连接串，访问密码是“admin123”。这不是代码问题，是管理问题。

所以自评的第一步，不是打开扫描器，而是拿张纸，把资产列清楚。域名、IP、端口、API接口、第三方组件、人员权限，一个都别漏。漏了就等于没评。

扫描器能告诉你一半的真相

Nessus、AWVS、Xray这些工具跑一遍，能出一堆报告。但别急着复制粘贴。工具报的“高危”里，至少三成是误报或者环境依赖导致不可利用。反过来，工具扫不出来的逻辑漏洞——比如越权查看他人订单、优惠券无限刷——才是真正要命的。

我的习惯是：扫描结果先人工验证一遍，能复现的才写进报告。不能复现的，标注“待确认”，别直接删。有一次客户坚持说某个SQL注入是误报，我当着他面用sqlmap跑出数据库名，他就不说话了。

风险等级别照搬CVSS

CVSS分数高不代表你就要连夜修。一个只在内网开放、需要域管理员权限才能触发的漏洞，跟一个公网直接RCE的漏洞，修复优先级完全不同。自评报告里得写清楚：这个漏洞利用条件是什么？攻击者需要什么权限？影响范围是单点还是整个集群？

我通常分三档：立刻修（公网可利用、无需认证、影响核心数据）、排期修（需要一定条件、影响有限）、观察（理论存在但实际很难触发）。别把所有高危都写成“紧急”，那样反而没人当回事。

修复建议要具体到人能动手

“加强输入验证”这种话等于没说。得写成：“在/api/user/update接口的nickname参数处，增加长度限制和特殊字符过滤，过滤规则参考OWASP Cheat Sheet第X条。”最好附上修复后的验证方法——比如发一个包含单引号的请求，看返回是否正常。

还有一点，自评报告里要留“未修复项”的跟踪表。谁负责、截止日期、当前状态。我见过太多报告写完就归档，三个月后同一个漏洞还在。那不是自评，那是自欺。

最后说个扎心的观察

大部分中小团队做自评，不是因为真觉得安全重要，而是甲方要求、等保测评要过、或者出了事得有个交代。这种心态下出来的报告，往往避重就轻，把真正的问题藏在附录里。如果你拿到一份自评报告，通篇都是“低风险”“建议优化”，一个“高危”都没有，那大概率不是系统安全，而是写报告的人不敢写。

漏洞不会因为你没写进报告就消失。它只是安静地待在那里，等一个不请自来的访客。