安全漏洞情报数据中不包括cvss评分信息

很多安全团队在搭建漏洞情报管道时，安全默认把CVSS评分当作漏洞数据的漏洞一部分。实际情况是情报，绝大多数漏洞情报源根本不包含CVSS评分。数据你从NVD、包括CVE、评分厂商公告、信息暗网论坛、安全安全研究员的漏洞Twitter推文里拿到的原始数据，通常只有漏洞描述、情报受影响产品、数据利用条件、包括PoC状态这些字段。评分CVSS是信息后来才被某个环节贴上去的标签。

我去年帮一个金融客户做漏洞优先级排序系统时就踩过这个坑。安全他们的数据管道从五个情报源抓取漏洞信息，开发同学写了个解析器，假设每个漏洞记录里都有cvss_score字段。上线第一天就炸了——超过60%的记录该字段为空。更麻烦的是，那些有评分的记录，来源五花八门：NVD给的是CVSS v3.1，某个厂商公告只写了v2的分数，另一个商业情报源干脆自己算了个“风险分”但没标版本。把这些数字混在一起排序，结果毫无意义。

为什么漏洞情报数据里没有CVSS？先得搞清楚CVSS到底是什么。它是一套评估框架，不是漏洞的固有属性。同一个CVE，NVD分析师给7.5分，红队研究员可能因为利用链复杂只给5.0，而某个自动化扫描器为了引起注意直接标9.8。评分取决于评估者的立场、可用信息和评分时的上下文。情报源只负责收集和分发原始事实，评分是消费方根据自己的资产、暴露面和威胁模型去做的判断。

举个具体例子。CVE-2023-44487（HTTP/2 Rapid Reset）刚公开时，NVD的CVSS v3.1评分是7.5。但Cloudflare和Google的安全团队在内部评估时，考虑到自家边缘节点的暴露情况，实际修复优先级远高于7.5对应的级别。反过来，一个只在内网测试环境跑着旧版nginx的团队，可能把同样这个漏洞降到5分以下处理。情报源如果硬塞一个CVSS评分进去，反而会误导下游团队。

另一个现实原因是数据生产链条的分工。CVE编号由MITRE分配，漏洞描述由CNA（CVE编号授权机构）提供，NVD做二次分析并打分——但NVD的打分经常滞后，有时漏洞公开后几周甚至几个月才补上CVSS。商业漏洞情报平台（比如Recorded Future、Flashpoint）的核心价值在于暗网监控、早期预警和上下文关联，它们不负责做CVSS评分，那是客户自己的事。开源情报源更不用说，一个安全研究员发推说“我找到了某路由器的RCE”，他不会顺手算个CVSS向量。

这给安全工程带来的直接后果是：你不能指望从情报数据里直接读出一个分数来做决策。正确的做法是在数据管道里加一个评分层。这个层需要做几件事——把不同来源的漏洞记录做实体对齐（同一个CVE可能来自多个源），检查是否有可用的CVSS向量字符串（注意不是分数，向量字符串才能重新计算），如果没有就根据漏洞类型、利用条件、受影响组件的资产重要性去生成一个内部评分。这个内部评分才是你排序和分派的依据。

我见过一些团队试图用机器学习模型从漏洞描述文本里预测CVSS分数。效果怎么说呢，在公开数据集上能跑出0.8的R²，但一到真实环境就崩。因为描述文本里缺失的关键信息太多了：攻击向量是网络还是本地？需不需要认证？影响是 confidentiality 还是 availability？这些字段在原始情报里经常是空的。模型只能靠猜。

所以下次你设计漏洞管理流程时，别在数据接入层找CVSS。把它当成一个需要自己构建的评分服务。情报数据给你的是原材料——漏洞是什么、影响谁、有没有在野利用。CVSS是你根据这些原材料和自身环境炒出来的菜。指望情报源直接端上一盘炒好的菜，要么饿着，要么吃到一盘不知道谁炒的、放了什么调料的菜。