📚 课程目录第4章漏洞数据库与情报源

4. 漏洞数据库与情报源：NVD、OSV、GitHub Advisory Database、漏洞评分体系（CVSS v3/v4）

做 SBOM 响应，最怕什么？

怕漏洞情报不准，怕评分虚高，怕修了半天发现是个误报。

我刚开始搭建漏洞响应系统时，就踩过这个坑。当时全量接入了一个开源情报源，结果每天告警上千条，团队疲于奔命。后来才发现，很多漏洞根本不影响我们的实际运行环境。说白了，情报源的质量直接决定了你的响应效率。

这一章，我们就来聊聊主流的漏洞数据库和评分体系。我会结合自己的实战经验，帮你理清它们各自的特点和适用场景。

4.1 主流漏洞数据库：三足鼎立

目前业界用得最多的，主要是三个：NVD、OSV 和 GitHub Advisory Database。它们各有侧重，我习惯把它们看作“官方档案”、“社区快照”和“生态雷达”。

4.1.1 NVD（National Vulnerability Database）

NVD 是美国政府的官方漏洞库。它最大的特点是权威、全面、有 CVSS 评分。几乎所有公开的 CVE 都会收录在这里。

但说实话，NVD 也有明显的短板：更新慢。一个漏洞从公开到被 NVD 收录，平均要等 5-15 天。对于 0-day 或活跃利用的漏洞，这个延迟是致命的。

我在项目中遇到过，某次 Log4j 漏洞爆发，NVD 的评分和补丁信息比社区慢了整整一周。那一周里，我们只能靠其他情报源做应急响应。

我的建议： NVD 适合做基线库和合规审计，不适合做实时告警。把它当作“最终裁决者”，而不是“第一响应者”。

4.1.2 OSV（Open Source Vulnerabilities）

OSV 是 Google 牵头做的开源漏洞库。它的特点是机器可读、更新快、直接关联到开源包的版本范围。

OSV 的数据格式非常简洁，一个 JSON 就能描述清楚漏洞影响哪些版本。我特别喜欢它的 API，可以直接用包名和版本号查询，返回结果秒级响应。

举个例子，你用 pip 装了一个库，想知道有没有漏洞。用 OSV 的 API 查一下，几毫秒就知道结果。这在自动化 SBOM 扫描中非常实用。

# OSV API 查询示例
curl -X POST https://api.osv.dev/v1/query \
  -H "Content-Type: application/json" \
  -d '{
    "package": {
      "name": "lodash",
      "ecosystem": "npm"
    },
    "version": "4.17.20"
  }'

返回结果会告诉你这个版本有没有漏洞，以及对应的修复版本。嗯，这才是 DevSecOps 该有的效率。

4.1.3 GitHub Advisory Database

GitHub Advisory Database 是 GitHub 维护的漏洞库。它最大的优势是生态整合——直接关联到 GitHub 上的仓库、Dependabot 告警和 Security Advisories。

如果你用 GitHub 托管代码，这个库几乎是零成本接入。Dependabot 会自动扫描你的依赖，匹配 Advisory Database 中的漏洞，然后直接提 PR 升级。

我个人习惯把 GitHub Advisory Database 作为“第一道防线”。它覆盖了 npm、Maven、PyPI、Go 等主流生态，而且更新速度比 NVD 快得多。

  一句话总结：
  NVD：官方权威，适合合规和基线
OSV：机器友好，适合自动化扫描
GitHub Advisory：生态整合，适合日常告警

4.2 漏洞评分体系：CVSS v3 与 v4

有了漏洞库，怎么判断漏洞的严重程度？这就轮到 CVSS 出场了。

CVSS（Common Vulnerability Scoring System）是目前最通用的漏洞评分标准。它把漏洞的严重程度量化为 0-10 分，分数越高越危险。

4.2.1 CVSS v3 的核心指标

CVSS v3 的评分由三个维度组成：

维度	指标	说明
基础指标	AV/AC/PR/UI/S/C/I/A	漏洞本身的固有属性，不可改变
时间指标	E/RL/RC	随时间变化的因素，如利用代码成熟度
环境指标	CR/IR/AR/M	根据实际环境调整，如资产重要性

基础指标是最常用的。它包含 8 个参数：

AV（攻击向量）：网络、相邻网络、本地、物理
AC（攻击复杂度）：低、高
PR（权限要求）：无、低、高
UI（用户交互）：无、需要
S（影响范围）：不变、改变
C/I/A（机密性/完整性/可用性影响）：无、低、高

你想想看，一个漏洞如果攻击向量是“网络”、攻击复杂度是“低”、不需要权限、不需要用户交互，那基本就是高危中的高危了。

4.2.2 CVSS v4 的变化

CVSS v4 在 2023 年底正式发布。相比 v3，它做了几个重要调整：

新增“攻击要求”（AT）：区分是否需要特殊配置或条件
细化“影响范围”：不再用“改变/不变”，而是直接评估对相邻系统的影响
增加“安全”维度：把 CIA 扩展到“安全”（Safety），覆盖工控和物联网场景
改进评分公式：减少极端值，让评分更平滑

我在做设备 SBOM 时，发现 v4 对 IoT 设备特别友好。以前很多工控漏洞在 v3 下评分偏低，因为只考虑了 IT 场景。v4 加入了“安全”维度后，这些漏洞的严重程度才被真正体现出来。

避坑指南： 我曾经遇到过，一个漏洞在 NVD 上显示 CVSS v3 评分 7.5（高危），但实际在我们的环境中，因为网络隔离和权限控制，真实风险只有 3.0 左右。所以，不要直接拿 NVD 的评分当决策依据。一定要结合自己的环境指标重新计算。

4.3 情报源的整合策略

单一情报源永远不够。我建议采用“分层整合”的策略：

第一层：实时告警 —— 用 GitHub Advisory Database 或 OSV，做日常依赖扫描
第二层：深度分析 —— 用 NVD 获取完整的 CVE 描述、参考链接和补丁信息
第三层：环境校准 —— 用 CVSS 环境指标重新计算，过滤掉不影响你的漏洞

这样做的好处是，告警量能减少 60%-80%，而且留下的都是真正需要处理的。

4.4 知识体系总览

下面这张图，帮你理清漏洞数据库、情报源和评分体系之间的关系：

4.5 实战建议

最后，分享几个我在项目中沉淀下来的经验：

不要迷信 CVSS 分数。同样的漏洞，在不同环境里风险天差地别。我见过一个 CVSS 9.8 的漏洞，因为资产在内网且无法出网，实际风险几乎为零。
OSV 适合做自动化。它的 API 响应快、格式简单，非常适合集成到 CI/CD 流水线中。
GitHub Advisory 适合做日常。如果你用 GitHub，直接开 Dependabot 就行，省心省力。
NVD 适合做合规。审计和合规检查时，NVD 的数据最权威，也最容易被接受。

嗯，情报源的选择没有银弹。关键是根据自己的场景，搭配合适的源和评分策略。下一层，我们会聊聊如何把这些情报源集成到 SBOM 扫描流水线中。