内容摘要：去年某次内部攻防演练，一个看似不起眼的文件上传接口成了突破口。攻击队上传了一个伪装成图片的JSP文件，服务器直接把它解析执行了。事后复盘，开发人员说“没想到有人会传这种文件”。这个“没想到”，就是漏洞

去年某次内部攻防演练，软件一个看似不起眼的漏洞文件上传接口成了突破口。攻击队上传了一个伪装成图片的评估JSP文件，服务器直接把它解析执行了。软件事后复盘，漏洞开发人员说“没想到有人会传这种文件”。评估这个“没想到”，软件就是漏洞漏洞评估要解决的核心问题——不是等出了事再补，而是评估提前把那些“没想到”找出来。

软件漏洞评估跟渗透测试经常被混为一谈。软件渗透测试更像实战模拟，漏洞目标是评估拿下系统；漏洞评估则偏向系统化排查，把代码、软件配置、漏洞依赖、评估架构各个层面的弱点翻出来，排个优先级。前者看能不能打进去，后者看有多少扇门没锁。两者互补，但目的不同。

做评估第一步是摸清资产边界。听起来很基础，实际操作中经常翻车。我见过一个项目，开发团队信誓旦旦说对外只暴露了三个端口，结果一扫，八百多个。原因是有台测试服务器忘了关，上面跑着半年前的代码，数据库密码还是默认的。资产清点不准确，后面的评估全是空中楼阁。

接下来是漏洞识别。手段无非几种：静态代码扫描、动态扫描、依赖组件比对、人工审计。工具能覆盖大部分已知漏洞模式，比如SQL注入、XSS、命令执行这些。但工具的通病是误报率高。某次用SAST工具扫一个Java项目，报了三百多个“高危”，人工过了一遍，真正可利用的不到十个。剩下的大多是框架内部调用或者已有过滤逻辑的路径。纯靠工具出报告，开发团队很快就会对漏洞评估失去信任。

人工审计的价值在逻辑漏洞上体现得最明显。工具很难理解“这个接口虽然校验了用户身份，但没校验用户是否有权操作这条数据”这类问题。去年有个电商项目，订单查询接口只验证了登录态，没验证订单归属。改一下订单ID就能看到别人的收货地址和电话。这种漏洞扫描器基本扫不出来，得靠人盯着业务逻辑一行行捋。

依赖组件是另一个重灾区。Log4j2那个事就不用多说了，影响面之大至今让人心有余悸。问题是很多团队对自己用了哪些第三方库根本没数。一个项目引了A库，A库又引了B库，B库引了C库，C库出了漏洞，你连它存在都不知道。SBOM（软件物料清单）这个概念喊了几年，真正落地的团队还是少数。

漏洞评估报告怎么写也有讲究。见过太多报告把CVSS评分一列，按分数从高到低排完事。但CVSS 9.8的漏洞如果在一个内网隔离环境里，实际风险可能还不如一个公网边缘的CVSS 5.0。评估要结合业务场景、网络暴露面、数据敏感度来定级。不然开发团队修了一堆“高危”，真正的风险点还在那儿敞着。

修复环节是最容易断链子的。评估团队出了报告，开发团队说排期满了，运维说不敢随便改配置。一个中危漏洞从发现到修复拖了四个月，期间被外部 researcher 报了同样的洞，尴尬得很。漏洞评估不是交完报告就结束，得跟着修复走，验证修复效果，确认没有引入新问题。

说到底，漏洞评估是个持续过程，不是一次性项目。代码在变，依赖在更新，攻击手法在进化。今天评估完没问题的系统，下个月引入一个新组件可能就带进来三个CVE。把它嵌到CI/CD流程里，每次发版前自动跑一遍，比每年搞一次大扫除管用得多。