2027年起微软强制WHCP驱动提交SBOM和VEX，否则无法签名

2027年3月起，针对Windows 11 25H2、26H1及Windows Server 2025的驱动提交必须同时提供有效SBOM和VEX声明，否则无法通过WHCP签名认证。 微软9月2日公告明确，此举属于WHCP政策调整，目标是提升驱动生态的安全性与完整性，同时满足欧盟CRA合规要求。

SBOM强制要求驱动暴露全部组件版本

从2027年3月开始，提交到WHCP的任何驱动程序都必须附带一份机器可读的软件物料清单。SBOM需要列出驱动中使用的所有第三方组件、开源库、固件模块以及它们的精确版本号、供应商信息和许可证类型。

这一要求的核心是把过去封闭的驱动二进制文件变成可审计的供应链记录。过去开发者只需保证最终驱动能通过签名测试，现在必须把内部依赖全部摊开。微软希望借此让Windows生态从“黑箱”转向透明，一旦某个开源组件爆出高危漏洞，微软和企业用户能立刻知道哪些驱动受影响。

对供应链安全而言，SBOM是基础数据层。它不直接修漏洞，而是提供“已知成分表”。没有这份表，安全团队就无法进行精准的漏洞影响分析，只能靠大规模扫描或等待厂商公告，效率极低。微软把SBOM纳入WHCP，等于把供应链透明变成驱动上架的硬性前提。

这一变化对驱动开发者意味着工作流程必须前置。以前在开发后期才考虑合规，现在从项目启动就要维护一份持续更新的SBOM，并在每次构建时自动生成最新版本。信号显示，这一要求适用于Windows 11 25H2、26H1以及后续所有版本，覆盖范围相当广。

VEX声明用于标注漏洞真实可利用风险

2027年起微软强制WHCP驱动提交SBOM和VEX，否则无法签名：VEX声明用于标注漏洞真实可利用风险

单独的SBOM只能告诉用户“里面有什么”，VEX则回答“这些东西里哪个漏洞真的能被利用”。VEX文件以JSON格式声明特定CVE在当前驱动版本中的状态：是否受影响、是否已缓解、是否需要用户采取额外行动。

微软要求SBOM和VEX必须同时提交且保持有效。这意味着当一个被SBOM列出的组件存在已知CVE时，开发者必须在VEX里明确写明该漏洞在本驱动上下文里是否可被利用。如果VEX声明“not affected”或“fixed”，就能大幅降低安全团队的优先级判断成本。

VEX的实际作用是过滤噪声。现代软件供应链里，一个驱动可能引入几十个已知漏洞，但其中大部分在特定编译选项、运行环境或代码路径下根本无法触发。VEX让厂商把这些判断结果正式化，避免每个下游用户重复做相同分析。

这一对文件的要求直接改变了漏洞响应流程。过去依赖通用漏洞数据库，现在多了一层厂商背书的上下文声明。对Windows生态来说，这相当于把供应链安全从“发现漏洞”推进到“判断影响”阶段。

WHCP新规直接服务欧盟CRA合规目标

微软在公告中明确指出，此次WHCP政策调整旨在满足欧盟《网络韧性法案》（CRA）。CRA要求硬件和软件产品在投放欧盟市场前必须证明自身具备足够的网络韧性，其中重要一条就是供应链透明和漏洞管理能力。

通过强制SBOM和VEX，微软把原本可能需要单独应对的合规工作前置到驱动签名环节。凡是打算继续在欧盟销售Windows设备的OEM厂商，其驱动供应商必须先满足WHCP新规，否则整个产品链条都无法合规。

这一联动意味着WHCP不再只是微软自己的质量计划，而是变成了跨司法管辖区的合规工具。欧盟CRA对产品全生命周期的安全要求被微软转化成具体的文件提交义务，驱动开发者实际上在帮OEM承担部分CRA责任。

对中国企业而言，这条路径清晰：想继续服务全球市场，尤其是欧洲市场，就必须按微软的时间表准备好SBOM和VEX。信号显示，新规从2027年3月开始执行，给出的准备时间约为一年半。

中国驱动开发者需升级SBOM生成工具链

对中国驱动开发者来说，2027年的门槛主要体现在工具和流程上。目前多数团队仍以手动或半自动方式维护组件清单，难以满足WHCP对机器可读、实时更新SBOM的要求。

开发者需要引入或升级SBOM生成工具，支持SPDX或CycloneDX格式，能在CI/CD流水线中自动扫描源码、依赖和二进制文件，输出带数字签名的SBOM。开源工具如Syft、Trivy或商业方案都需要进行本地化适配，以处理国内常用编译链和驱动框架。

除了工具，开发者还必须建立组件治理流程：禁止使用来源不明的代码，定期更新依赖，记录每个组件的引入理由和许可证信息。这些记录将成为VEX声明的基础。

短期内，小型驱动团队可能面临成本压力。升级工具链、培训人员、调整现有项目都需要投入。但长期看，这会倒逼中国驱动产业向标准化、透明化方向发展，提升在全球供应链中的可信度。

OEM厂商供应链管理将面临审计压力

OEM厂商是WHCP新规的最终责任方。他们需要确保所有上游驱动供应商都能按时提供有效SBOM和VEX，否则自己的设备就无法获得Windows签名认证，进而影响在欧盟的销售。

这意味着OEM必须把SBOM/VEX要求写入供应商合同，并建立定期审计机制。过去只看驱动是否通过WHCP测试，现在还要审查供应商的SBOM生成流程是否可信、VEX声明是否有依据。

供应链审计压力将从Tier 1驱动商一直传导到更下游的固件和IP供应商。OEM需要建设统一的供应链安全平台，把所有SBOM汇聚起来，进行集中漏洞扫描和风险评估。

对中国OEM而言，这既是挑战也是机会。那些能快速整合供应商、建立透明供应链的厂商，将在欧盟CRA合规竞争中获得优势。反之，依赖零散小厂、缺乏管理能力的OEM可能会面临交付延误或认证失败的风险。

安全合规团队可利用VEX缩短漏洞响应

对企业安全合规团队来说，VEX是这次政策里最有实战价值的部分。它让漏洞管理从“海量告警”变成“精准处置”。当微软或第三方披露某个驱动相关CVE时，团队可以直接读取对应VEX声明，快速判断该漏洞在本企业部署的设备上是否构成真实风险。

合规团队应尽快建立VEX解析流程，将其接入现有漏洞管理平台。理想状态下，SBOM和VEX数据能自动导入资产数据库，实现驱动级别的漏洞影响视图。

建议做法包括：培训团队理解VEX的各种状态字段；制定VEX验证规则，对供应商声明进行抽样审计；将VEX作为采购前评估的重要依据。

长远来看，VEX能显著缩短从漏洞披露到完成风险评估的时间。过去可能需要数周的分析工作，在有完整VEX的情况下可能几天内就能完成。这对大型企业尤其是金融、制造等对合规要求高的行业，价值明显。

微软此次调整把供应链安全要求固化到驱动认证环节。中国开发者、OEM和安全团队都需要在2027年3月前完成相应准备。SBOM带来透明，VEX提供判断，两者结合正在重塑Windows驱动生态的安全基线。

参考来源