漏洞信息采集：NVD、CNNVD、CNVD 与 GitHub Advisory 实战
做漏洞管理，第一步不是去翻 CVE 编号，而是搞清楚「去哪儿查、怎么查、查完怎么用」。我见过不少团队，拿着一个 CVE 号就去打补丁，结果补丁打错了版本，或者压根没影响自己的组件。说白了，信息采集这一步没走稳，后面全是坑。
这一章，我带你过一遍四个主流数据源：NVD、CNNVD、CNVD 和 GitHub Advisory Database。每个都有它的脾气，也有它的价值。
2.1 NVD 数据库：全球漏洞的「官方档案」
NVD（National Vulnerability Database）是美国 NIST 维护的漏洞库。它不生产 CVE，但给每个 CVE 打上了「结构化标签」——CVSS 评分、CPE 匹配、CWE 分类。我个人习惯，所有漏洞分析的第一步，永远是去 NVD 确认基础信息。
2.1.1 怎么高效查 NVD？
NVD 的搜索其实挺灵活的。你可以在搜索框里直接拼关键字，也可以用它的高级过滤。我常用的几个技巧：
- 按时间范围过滤：
pubStartDate=2024-01-01&pubEndDate=2024-12-31，适合做月度漏洞盘点。 - 按 CVSS 分数排序：
cvssV3Severity=CRITICAL，只看高危。 - 按 CPE 匹配产品：比如
cpe:2.3:a:apache:log4j，直接定位到组件。
我的小技巧：NVD 的 API 比网页搜索好用得多。写个脚本每天拉一次增量数据，比手动翻页效率高十倍。我曾经用 Python 写了个定时任务，每天凌晨拉取前 24 小时的新增 CVE，然后自动匹配内部资产清单。
2.1.2 CPE 匹配：别小看这个字段
CPE（Common Platform Enumeration）是 NVD 的灵魂。每个 CVE 会关联一组受影响的 CPE 字符串。比如：
cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*
这个字符串拆开看：a 表示应用，apache 是厂商，log4j 是产品名，2.14.1 是版本。你想想看，如果你的资产清单里也维护了 CPE 字段，那匹配就是秒级的事。
注意：CPE 匹配不是万能的。有些厂商的产品名写得不规范，比如「Windows 10」和「Windows_10」可能同时存在。我建议你在做自动化匹配时，先做一次 CPE 标准化清洗。
2.2 CNNVD 与 CNVD：国内漏洞库的「双生子」
做国内合规或者等保项目时，NVD 有时候不够用。CNNVD（中国国家漏洞数据库）和 CNVD（国家信息安全漏洞共享平台）是必须了解的两个库。很多人分不清它们，我简单说说差异。
| 对比维度 | CNNVD | CNVD |
|---|---|---|
| 维护单位 | 中国信息安全测评中心 | 国家互联网应急中心（CNCERT） |
| 编号格式 | CNNVD-202412-3456 | CNVD-2024-12345 |
| 覆盖范围 | 偏向通用软硬件漏洞 | 偏向国内行业、工控、物联网 |
| CVSS 评分 | 有，但更新有时滞后 | 部分漏洞有自评 |
| 补丁信息 | 相对完整 | 部分漏洞有厂商修复建议 |
| 适用场景 | 等保合规、政府项目 | 国内资产、行业监管 |
我个人经验是：做国际业务优先看 NVD，做国内合规两个都得看。CNNVD 的编号和 NVD 的 CVE 有映射关系，但 CNVD 的编号体系是独立的，有时候同一个漏洞在 CNVD 里会有更详细的国内影响范围描述。
避坑指南：我曾经遇到一个工控漏洞，NVD 上只写了影响 Siemens 某款 PLC，但 CNVD 里补充了「该漏洞已被国内某厂商的 ODM 产品使用」。如果只看 NVD，你可能会漏掉这部分资产。
2.3 GitHub Advisory Database：开源社区的「实时情报」
GitHub Advisory Database 是 GitHub 维护的漏洞库，专门针对开源生态。它的特点是：更新快、直接关联仓库、有修复 commit。我特别喜欢它的「Advisory」页面，每个漏洞都直接链到受影响的 GitHub 仓库和修复 PR。
2.3.1 怎么用 GitHub Advisory？
你可以在 github.com/advisories 直接搜索，也可以用 GitHub 的 API。我常用的方式：
- 按生态过滤：比如
ecosystem:npm只看 npm 包。 - 按严重程度：
severity:critical。 - 查看修复 commit：每个 Advisory 都有
Patched Versions和Fixed Commit字段。
# 用 gh CLI 查询某个仓库的漏洞
gh api /advisories?ecosystem=npm&per_page=10
嗯，这里要注意：GitHub Advisory 的数据会同步到 NVD，但通常比 NVD 快 1-3 天。对于紧急漏洞，我建议直接盯 GitHub Advisory。
2.3.2 实战：用 GitHub Advisory 做补丁溯源
假设你发现一个 npm 包有漏洞，但不知道具体修在哪一版。去 GitHub Advisory 搜一下，直接看 Patched Versions 和 Fixed Commit。我举个例子：
- 漏洞：CVE-2024-1234
- 影响：lodash < 4.17.21
- 修复 commit：
abc123 - 修复版本：4.17.21
有了这些信息，你就能精确判断：当前用的版本是否在影响范围内，以及升级到哪个版本能彻底修复。
我的习惯：把 GitHub Advisory 的 RSS 订阅到内部监控系统。一旦有新的 Advisory 发布，自动触发资产匹配和告警。比等 NVD 更新快不少。
2.4 知识体系总览：一张图看懂漏洞信息采集
下面这张图，我把四个数据源的核心流程和关系画出来了。你可以把它当作本章的「地图」。
2.5 实战建议：怎么组合使用这四个数据源？
我自己的流程是这样的，你可以参考：
- 日常监控：GitHub Advisory RSS + NVD API 每日增量拉取。
- 漏洞分析：先去 NVD 看 CVSS 和 CPE，再去 GitHub Advisory 看修复 commit。
- 国内合规：交叉查 CNNVD 和 CNVD，确认国内影响范围和监管要求。
- 补丁决策：综合四个数据源的补丁信息，确定最小修复版本。
核心原则：多源交叉验证，不依赖单一数据源。NVD 可能更新慢，CNVD 可能覆盖不全，GitHub Advisory 可能只针对开源。只有组合使用，才能拿到最完整的漏洞画像。
好了，这一章的内容就到这里。信息采集是漏洞管理的「地基」，地基稳了，后面的匹配和优先级排序才能站得住脚。