4、漏洞数据库：NVD、GitHub Advisory、OSV、国内CNNVD
做供应链安全，最核心的一件事就是：你得知道你的组件到底有没有漏洞。
这话听起来像废话，对吧？但实际工作中，我发现很多团队连漏洞数据从哪查都不清楚。有人只盯着NVD，有人只看GitHub的Release Note，还有人全靠邮件订阅碰运气。说实话，这几种方式都不够。
这一章，我就带你把这四个主流漏洞数据库捋一遍。NVD、GitHub Advisory、OSV、CNNVD，它们各自擅长什么、短板在哪、怎么配合使用。搞清楚了，你才能搭建一套靠谱的漏洞监控体系。
4.1 NVD：老大哥，但有点慢
NVD（National Vulnerability Database）是美国NIST维护的官方漏洞库。它最大的优势是权威——所有CVE编号都从这里流出。基本上，你听到的任何一个CVE-2024-XXXXX，最终都会在NVD里找到详细记录。
但NVD有个硬伤：更新慢。我遇到过好几次，某个组件在GitHub上已经被标记为高危漏洞了，NVD那边还显示“正在分析中”。一等就是好几天。对于供应链审计来说，这个延迟是致命的。
NVD的核心数据字段：CVE编号、CVSS评分、影响版本范围、参考链接、CWE分类。
我个人习惯把NVD当作最终仲裁者。也就是说，日常监控不靠它，但做正式审计报告时，必须引用NVD的数据作为权威依据。
4.2 GitHub Advisory：快，而且准
GitHub Advisory Database是GitHub官方维护的漏洞库。它跟NVD最大的区别是：快。
为什么快？因为很多漏洞是安全研究员直接在GitHub上提交的。比如某个开源项目的维护者发现了漏洞，他会先发一个Security Advisory给GitHub，GitHub审核通过后，这个漏洞就立刻进入数据库了。这时候NVD可能还在排队。
我记得有一次审计一个Node.js项目，NVD上完全查不到某个lodash的漏洞信息，但GitHub Advisory里已经标注了“影响版本<4.17.21”。我直接根据这个数据锁定了修复版本，省了不少时间。
使用技巧：GitHub Advisory支持通过gh命令行工具查询，也可以直接调用它的GraphQL API。对于托管在GitHub上的项目，这是最直接的漏洞来源。
GitHub Advisory的另一个好处是数据格式统一。它遵循OSV（Open Source Vulnerability）格式，方便程序化处理。这一点，后面讲OSV时会细说。
4.3 OSV：开源漏洞的“统一接口”
OSV（Open Source Vulnerability）是Google牵头搞的一个项目。它的目标很简单：把各种漏洞数据库统一成一个格式。
你想想看，NVD有NVD的格式，GitHub Advisory有自己的JSON Schema，国内CNNVD又是另一套。每次对接一个数据库，都要写一套解析代码，烦不烦？OSV就是来解决这个问题的。
OSV的核心特点：
- 统一的JSON Schema描述漏洞信息
- 支持通过Package URL（purl）精确定位组件
- 提供REST API和gRPC接口，查询效率高
- 数据源包括NVD、GitHub Advisory、PyPI、Go等
我现在的做法是：把OSV作为第一查询入口。因为它聚合了多个数据源，而且API响应速度快。比如我要查一个npm包有没有漏洞，直接调OSV的API，传个purl进去，几毫秒就返回结果了。
# 示例：通过OSV API查询lodash的漏洞
curl -X POST https://api.osv.dev/v1/query \
-H "Content-Type: application/json" \
-d '{
"package": {
"name": "lodash",
"ecosystem": "npm"
},
"version": "4.17.20"
}'返回结果里会列出所有匹配的漏洞ID、影响版本范围、修复版本。嗯，这个接口我几乎每天都在用。
4.4 CNNVD：国内合规必备
CNNVD（中国国家漏洞数据库）是国内官方维护的漏洞库。说实话，它的数据完整性和更新速度跟NVD比还有差距。但为什么还要提它？因为合规。
如果你做的是国内政企项目，或者需要通过等保测评，那CNNVD的数据是必须参考的。有些监管要求明确写了“以CNNVD发布的漏洞信息为准”。这时候，你光看NVD是不够的。
避坑提醒：CNNVD的CVE编号有时跟NVD不一致。我曾经遇到过一个漏洞，CNNVD给的编号是CNNVD-202312-1234，但NVD里对应的CVE是CVE-2023-45678。做审计报告时，最好两个编号都写上，避免被挑刺。
CNNVD的查询方式比较传统，主要是通过官网搜索。它也有API，但需要申请权限，而且文档写得不太清楚。我个人建议：把CNNVD作为补充数据源，在正式审计报告中引用它的编号，日常监控还是以OSV和GitHub Advisory为主。
4.5 四个数据库的对比与选择
说了这么多，你可能有点晕：到底该用哪个？别急，我整理了一张对比表，看完就清楚了。
| 数据库 | 更新速度 | 数据完整性 | API支持 | 适用场景 |
|---|---|---|---|---|
| NVD | 慢（1-3天延迟） | 高（权威来源） | REST API（免费） | 正式审计报告、合规依据 |
| GitHub Advisory | 快（小时级） | 中（仅GitHub生态） | GraphQL API | 日常监控、GitHub项目审计 |
| OSV | 快（聚合多个源） | 高（聚合数据） | REST + gRPC | 第一查询入口、自动化扫描 |
| CNNVD | 慢（数天） | 中（国内合规） | 有限（需申请） | 国内政企项目、等保测评 |
我个人推荐的组合是：OSV做日常扫描 + GitHub Advisory做GitHub项目监控 + NVD做最终确认 + CNNVD做合规补充。这套组合下来，基本能覆盖90%以上的漏洞发现场景。
4.6 知识体系：漏洞数据库的核心逻辑
为了让你更直观地理解这四个数据库的关系，我画了一张结构图。它展示了漏洞数据从发现到消费的完整链路。
从这张图你能看到，OSV其实是一个聚合层。它从NVD、GitHub Advisory等源拉取数据，统一格式后提供给上层工具。这样做的好处是：你只需要对接OSV一个接口，就能拿到多个数据源的漏洞信息。
4.7 实战建议：搭建你的漏洞监控体系
最后，给你几个具体的建议，照着做就行：
- 优先接入OSV API：写一个定时任务，每天扫描一次你的组件清单，调OSV接口查漏洞。这是性价比最高的方式。
- GitHub项目开启Dependabot：如果你的代码托管在GitHub上，Dependabot会自动检测依赖漏洞并提PR。这个功能免费，别浪费。
- 定期拉取NVD全量数据：NVD提供JSON格式的全量数据导出，每周拉一次，用于生成正式审计报告。
- 国内项目额外查CNNVD：做等保或政企项目时，把CNNVD的查询结果附在报告里，避免合规问题。
小技巧：你可以用osv-scanner这个工具，它直接调OSV API，支持扫描Go、npm、PyPI、Maven等生态的依赖。一条命令就能出结果，省事。
好了，这一章的内容就是这些。四个数据库各有各的用处，别指望一个打天下。把它们组合起来用，你的供应链审计才能做到又快又准。