📚 课程目录第2章漏洞信息采集

漏洞信息采集：NVD API使用、CVE详情获取、CVSS评分解读、漏洞时间线分析

做漏洞匹配，第一步不是急着去翻CVE列表。你得先知道——数据从哪来，怎么拿，拿回来怎么看。

我见过不少团队，上来就写脚本爬各种漏洞库，结果爬回来的数据字段对不上、评分版本混乱、时间戳格式五花八门。最后花在清洗数据上的时间，比做匹配本身还多。

这一章，咱们就把信息采集这件事聊透。说白了，就是三件事：去哪拿、怎么拿、拿回来怎么用。

2.1 NVD API：官方数据源的正确打开方式

NVD（National Vulnerability Database）是目前最权威的CVE数据源。它提供RESTful API，免费、稳定、字段完整。我个人习惯把它作为所有漏洞数据的“锚点”。

小提示： NVD API 2.0 在2023年正式上线，旧版1.0已经废弃。如果你还在用旧版接口，建议尽快迁移。新版支持更灵活的过滤和分页。

2.1.1 API基础调用

NVD API的根地址是：https://services.nvd.nist.gov/rest/json/cves/2.0。最常用的参数就几个：

cveId — 精确查询某个CVE
pubStartDate / pubEndDate — 按发布时间范围过滤
cvssV3Severity — 按CVSS严重等级过滤（LOW/MEDIUM/HIGH/CRITICAL）
resultsPerPage / startIndex — 分页控制

举个实际例子。假设我要查最近一周内所有CRITICAL级别的漏洞：

GET https://services.nvd.nist.gov/rest/json/cves/2.0?pubStartDate=2025-01-20T00:00:00.000Z&pubEndDate=2025-01-27T00:00:00.000Z&cvssV3Severity=CRITICAL&resultsPerPage=20

注意： NVD API有速率限制。未注册API Key的情况下，30秒内最多30次请求。注册API Key后可以提升到50次/30秒。我曾经因为没注意这个限制，脚本跑了一半被限流，排查了半天才发现是请求太频繁。

2.1.2 响应结构解析

API返回的是JSON格式。核心字段集中在 vulnerabilities 数组里，每个元素包含：

字段路径	说明	使用场景
`cve.id`	CVE编号	唯一标识，匹配用
`cve.descriptions`	漏洞描述（多语言）	人工阅读、摘要生成
`cve.metrics.cvssMetricV31`	CVSS v3.1评分数据	风险优先级计算
`cve.published`	发布时间	时间线分析
`cve.lastModified`	最后修改时间	判断数据新鲜度
`cve.weaknesses`	CWE编号列表	漏洞类型归类
`cve.configurations`	受影响的产品/版本	资产匹配核心字段

嗯，这里要注意：configurations 字段的结构比较复杂，包含CPE（Common Platform Enumeration）匹配规则。后面讲资产匹配的时候，我会专门展开。

2.2 CVE详情获取：不止是编号和描述

很多人拿到CVE编号，就去搜一下描述，看看评分，然后就完事了。其实CVE详情里藏着很多关键信息，你想想看——

一个CVE条目里，除了基础信息，还有：

参考链接（references）：厂商公告、补丁链接、漏洞利用代码仓库。这些是判断漏洞是否“活”着的重要线索。
CWE映射：告诉你这个漏洞属于哪一类。比如CWE-79是XSS，CWE-89是SQL注入。分类对了，匹配策略才能对。
影响范围（affected products）：精确到版本号的CPE列表。这是做资产匹配的“靶心”。

  核心观点： CVE详情不是用来“读”的，是用来“解析”的。你的自动化系统应该能从详情里提取出：漏洞类型、受影响版本范围、是否有公开利用、补丁状态。这四个维度直接决定优先级。

2.3 CVSS评分解读：分数背后的逻辑

CVSS评分，很多人只看那个最终数字。8.5分就是HIGH，9.8分就是CRITICAL。但我在项目中踩过坑——同一个分数，背后的风险含义可能完全不同。

2.3.1 评分向量拆解

CVSS v3.1的评分由三个指标组构成：

指标组	包含指标	含义
Base（基础）	AV/AC/PR/UI/S/C/I/A	漏洞本身的固有属性
Temporal（时间）	E/RL/RC	随时间变化的风险因素
Environmental（环境）	CR/IR/AR/MAV/MAC/...	根据企业环境调整

举个例子。两个CVE都是CRITICAL（9.0分以上）：

CVE-A：AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 远程、无需认证、无需交互、完全危害。这是“核弹级”。
CVE-B：AV:A/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H — 需要物理或逻辑邻近、高复杂度、需要认证、需要用户交互。虽然也是CRITICAL，但利用条件苛刻得多。

你看，分数一样，风险差远了。所以我建议：不要只看分数，要看向量。向量才是评分背后的逻辑。

我的习惯： 在优先级排序时，我会把Base Score作为第一筛选条件，然后根据AV（攻击向量）和PR（权限要求）做二次加权。如果AV是Network且PR是None，优先级自动提升一级。

2.3.2 版本差异：v2 vs v3.1

现在NVD上很多CVE同时包含CVSS v2和v3.1评分。两者不可直接比较。v2的满分是10.0，v3.1也是10.0，但评分标准不同。比如：

v2的Access Vector分为Local/Adjacent Network/Network，v3.1细化为Physical/Local/Adjacent Network/Network
v2没有Privileges Required指标，v3.1引入了
v2的Confidentiality/Integrity/Availability只有None/Partial/Complete三档，v3.1改为None/Low/High

我曾经在做一个跨版本数据合并的项目时，直接把v2和v3.1的分数混在一起排序，结果排出来的优先级完全失真。后来花了整整两天重新清洗数据。

避坑指南： 如果你同时处理v2和v3.1的数据，务必分开存储、分开排序。或者统一转换成v3.1。NVD API返回的数据里，cvssMetricV31 和 cvssMetricV2 是分开的字段，不要混用。

2.4 漏洞时间线分析：从披露到利用的生命周期

一个漏洞从被发现到被大规模利用，通常遵循一定的时间规律。理解这个规律，能帮你判断“这个漏洞现在该不该优先处理”。

2.4.1 关键时间节点

一个典型的CVE时间线包含以下节点：

保留日期（reserved） — CVE编号被分配，但详情未公开
发布日期（published） — 漏洞详情首次公开
CVSS评分分配 — NVD完成分析并分配评分（通常在发布后几天到几周）
补丁发布 — 厂商发布修复版本
PoC/利用代码公开 — 概念验证代码或利用工具出现
大规模利用 — 被勒索软件或自动化扫描器集成
CISA KEV收录 — 美国CISA确认被积极利用

我个人习惯把时间线分成三个阶段：

窗口期（发布后0-7天）：信息不完整，评分可能未出，但攻击者已经开始分析
活跃期（7-30天）：PoC出现，利用尝试增多，这是最危险的阶段
衰退期（30天以上）：补丁普及，利用难度增加，但仍需关注

2.4.2 如何获取时间线数据

NVD API返回的 published 和 lastModified 是最基础的时间戳。但如果你想获取更完整的时间线（比如PoC公开时间、CISA KEV收录时间），需要结合其他数据源：

CISA Known Exploited Vulnerabilities Catalog：提供被确认积极利用的CVE列表及收录日期
Exploit-DB / GitHub：通过搜索CVE编号，可以找到PoC的发布时间
厂商安全公告：通常包含补丁发布日期

  实战建议： 建立一个时间线数据库，定期抓取NVD和CISA KEV的数据。当某个CVE被CISA KEV收录时，自动触发优先级提升。我在之前的项目中就是这样做的，效果很好。

2.5 知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以把它当作信息采集阶段的“操作地图”。

这张图展示了从数据源到最终输出的完整链路。你不需要一步到位，但心里要有这个框架。我刚开始做的时候，也是从最简单的NVD API调用开始，慢慢把CISA KEV和厂商公告加进来，最后才形成完整的采集流水线。

好了，信息采集这部分就聊到这。记住：数据质量决定匹配质量。花时间把采集和解析做好，后面的工作会顺畅很多。