📚 课程目录第4章第三方组件漏洞情报获取

4. 第三方组件漏洞情报获取

IoT固件中大量使用开源组件与第三方SDK，漏洞情报的完整性和时效性直接决定治理效果。很多团队只盯住CVE编号，结果漏掉了厂商私有编号、CNVD通报和IoT专用库中的设备级漏洞。本节从“情报源—采集—聚合—去重—入库”这条链路展开，重点讲清各源的特点、采集接口和去重判定方法。

一、五类情报源的定位与差异

不同情报源的覆盖范围、编号体系和更新节奏差异很大，混用之前必须先理解它们的定位。

CVE：由MITRE维护的全球通用编号，是漏洞的“身份证”。它只保证编号唯一，不保证描述完整，也不保证有CVSS评分。很多CVE在发布初期处于“RESERVED”状态，描述和评分后续才补齐。
NVD：美国国家标准与技术研究院基于CVE构建的增强库，补充CVSS评分、CPE匹配、CWE分类和参考链接。NVD的CPE是组件与版本映射的关键字段，但存在“分析滞后”，新CVE可能几天到几周后才完成富化。
CNVD：国家信息安全漏洞共享平台，覆盖大量国产软件、IoT设备和工控系统漏洞，很多漏洞只有CNVD编号而无CVE。对国内IoT产品而言，CNVD是不可替代的补充源。
厂商公告：芯片原厂、模组厂、云平台和开源项目的安全公告，通常包含受影响型号、固件版本、修复版本和缓解措施。厂商私有编号（如“Security Advisory 2024-001”）往往比CVE更早发布，且包含CVE未覆盖的配置类问题。
IoT专用漏洞库：如CISA ICS Advisory、Exploit-DB、VulDB以及各类固件漏洞研究库，聚焦路由器、摄像头、网关、RTOS和通信协议栈，包含大量设备级、协议级漏洞，是通用库的重要补充。

二、采集：接口、字段与增量策略

采集的核心是“按时间窗口增量拉取”，而不是每次全量下载。NVD提供REST API，支持按lastModStartDate和lastModEndDate过滤，适合做增量同步。CNVD和多数厂商公告没有稳定公开API，通常采用页面解析或RSS订阅，需要处理反爬和格式变化。

采集时必须保留的字段包括：源标识、源内唯一ID、CVE编号（可能为空）、标题、描述、发布时间、最后修改时间、CVSS向量与分值、受影响产品与版本、参考链接、原始JSON或HTML快照。其中“最后修改时间”是后续增量更新和去重的关键，不能只存发布时间。

# NVD增量采集示例（伪代码）
params = {
  "lastModStartDate": "2024-06-01T00:00:00.000",
  "lastModEndDate":   "2024-06-02T00:00:00.000",
  "resultsPerPage": 2000
}
for page in fetch_all_pages(NVD_API, params):
    for item in page["vulnerabilities"]:
        raw = item["cve"]
        record = {
            "source": "NVD",
            "source_id": raw["id"],
            "cve_id": raw["id"],
            "published": raw["published"],
            "last_modified": raw["lastModified"],
            "cvss": extract_cvss(raw),
            "cpe": extract_cpe(raw),
            "raw_snapshot": item
        }
        upsert(record)

厂商公告采集要额外记录“受影响型号”和“修复版本”，因为同一公告可能覆盖多个型号，而CVE描述里往往只写产品名。IoT专用库则要关注“攻击向量”和“是否需要物理接触”，这对设备风险定级影响很大。

三、聚合与去重：从编号到实体

聚合的目标是把同一漏洞在不同源中的记录合并成一条“漏洞实体”。去重不能只靠CVE编号，因为很多记录没有CVE，或者同一CVE在不同源中描述不同。推荐采用“三级去重”策略：

强匹配：CVE编号相同，直接合并。这是最可靠的一级。
弱匹配：无CVE时，用“厂商+产品+版本范围+漏洞类型”组合键匹配。例如“TP-Link+Archer C7+固件<1.0.5+命令注入”可视为同一漏洞。
模糊匹配：对标题和描述做文本相似度计算（如SimHash或余弦相似度），相似度超过阈值（示例取0.85）且发布时间接近的，进入人工复核队列，不自动合并。

合并时字段优先级建议：CVE编号以NVD为准；CVSS评分优先取NVD，缺失时取厂商公告；受影响版本取各源并集；修复版本取厂商公告；参考链接全部保留。这样既保证权威性，又不丢失信息。

去重后要保留“源记录映射表”，即一条漏洞实体对应哪些源ID。这样当某个源更新时，可以精准回溯和重新合并，而不是全量重算。

四、从采集到入库的完整链路

下面这张图展示了五类情报源经过采集、标准化、聚合去重后形成统一漏洞库，并输出给SBOM匹配和风险定级环节的完整数据流。

五、实践中的关键判断

采集频率建议：NVD和CNVD每日增量一次；厂商公告按订阅源每6小时检查一次；IoT专用库每周批量同步。去重阈值不要设得太低，否则会把不同漏洞误合并；也不要设得太高，否则同一漏洞会重复入库。示例中相似度阈值取0.85，实际应根据自身数据分布调整。

另一个容易忽略的点是“版本范围解析”。NVD的CPE使用versionStartIncluding、versionEndExcluding等字段表达范围，而厂商公告常用“低于1.0.5”这类自然语言。聚合时需要把两者统一成区间表示，否则SBOM匹配时会出现漏报或误报。建议在入库前增加一个版本范围校验步骤，对无法解析的范围标记为“待人工确认”。

不要直接把NVD的CPE当作唯一匹配依据。很多IoT组件在NVD中没有CPE，或者CPE粒度与固件实际组件不一致。必须结合厂商公告和SBOM中的组件标识做交叉验证。

最后，情报采集不是一次性任务。每次源更新后，应重新触发受影响漏洞的聚合与去重，并更新统一漏洞库中的“最后同步时间”。只有把采集、聚合、去重做成可重复运行的流水线，漏洞情报才能真正支撑IoT第三方组件的持续治理。