车载 SBOM 与 CVE 漏洞管理：如何判断漏洞是否真正影响 ECU？

某汽车控制器的 SBOM 包含 zlib 1.2.11。漏洞数据库返回一个 CVSS 9.8 的 CVE。产品安全经理现在需要回答的不是“数字是不是很高”，而是“这一漏洞是否真的影响本车载 ECU”。版本匹配只是调查起点，不是最终风险结论。

SBOM 解决的是“装了什么”

软件物料清单记录产品的软件组件、版本及相关标识。它让团队能够把每个 ECU 的实际软件库存与安全通告关联。CycloneDX 支持利用 PURL、CPE 等标识把组件和已知漏洞联系起来。^S10

库存要按实际 ECU 和交付软件版本维护。一个产品有多个控制器，同一库可能以不同版本出现。只用整车产品名代替 ECU 级软件版本，会让后续调查缺少具体对象。

CVE 版本命中之后，还要查什么？

先看受影响代码是否进入已交付固件。再查受影响函数能否被应用调用。接着判断攻击者是否能够把必要的数据送入该代码路径。最后才是影响车辆功能、数据或服务可用性的程度。

以 CVE-2022-37434 为例，NVD 描述了 zlib 在特定 gzip 头处理中的内存访问问题，并特别指出受影响场景需要应用调用 inflateGetHeader。仅发现 zlib 的版本处于公告范围内，不足以证明 MCU 实际可被利用。^S7

在实际分析里，工程师应核对构建清单、链接符号、调用关系、输入来源与测试证据。无法确认的地方应保持调查状态，不应为了清空待办列表而随意标记为“不受影响”。

CVSS 高分不等于产品风险一定高

CVSS 给出漏洞的通用严重性描述。整车和 ECU 风险还要结合实际攻击入口、执行条件、车辆功能与已有控制。一个需要本地物理操作的路径，与一个通过外部网络直接暴露的路径，必须分别分析。

工程师应留下两条信息：公开漏洞的原始严重性，以及在特定产品环境内得出的工程判断。不要把二者合并成一个无法解释的颜色标签。

VEX 记录的是经过判断后的产品状态

VEX 可以表达某个漏洞对具体组件或产品的影响，以及分析理由。CycloneDX 的 VEX 结构支持状态、理由和响应信息。比如“代码未被部署”“代码不可达”或“需要特定配置”。这些说明要有证据支撑。^S8

“计划下个版本修复”与“已经完成修复”不是同一结论。升级计划应保留目标版本、负责人和验证安排。完成修复后，应核对固件构建与软件清单是否真的更新。

给车载团队的一套调查顺序

收到新通告后，先匹配软件库存。随后检查实际部署、代码入口和攻击条件。再评估损害影响、记录控制与决定，最后安排修复或复审。每一步都要能指回原始通告和工程证据。

相关资产、攻击路径和控制若已存在于 TARA，应直接引用。这样漏洞管理不会成为独立于风险管理之外的另一个数据库。ISO/SAE 21434 将运行和维护阶段纳入网络安全工程生命周期。^S3

QuickTARA 在这个流程里做什么？

QuickTARA 将 SBOM 中的软件组件定位到 ECU，关联安全通告，并保留工程师对漏洞的调查决定。平台可导出 CycloneDX VEX。团队还可以查看该 ECU 周围已有的 TARA 资产、威胁和风险记录。

采购评估时，请要求演示同一个 CVE 从发现、调查到决定的全过程。特别要检查“不受影响”的解释如何保留，以及后续版本变化是否会覆盖先前判断。

常见问题

SBOM 匹配到了 CVE，就必须马上更换固件吗？ 不能单靠版本命中作决定。需要调查真实适用性、影响与风险处理。

VEX 可以代替修复吗？ 不可以。VEX 是状态和依据的表达，不是修复本身。

CVSS 9.8 能直接变成 ECU 高风险吗？ 不能。产品风险必须考虑实际架构、可达性和车辆损害。