微软将收紧 Windows 驱动签名：2027 年起 WHCP 提交需附 SBOM 与 VEX

据来源显示，微软已宣布调整 Windows 硬件兼容性计划（WHCP）的驱动签名政策：自 2027 年 3 月起，面向 Windows 11 25H2、26H1、Windows Server 2025 及后续版本提交驱动时，开发商必须同时提供有效的软件物料清单 SBOM 和漏洞可利用性信息交换 VEX 声明。微软当地时间 9 月 2 日发布的公告称，此举旨在提升 Windows 驱动生态的安全性与完整性，并配合欧盟《网络韧性法案》（CRA）等合规要求。

按照新规，如果相关驱动提交缺少 SBOM 或 VEX，或者文件未能通过验证，微软将不会提供 WHCP 签名。这意味着，驱动厂商未来不仅要关注功能、稳定性和兼容性，还需要把软件供应链透明度纳入正式交付流程。

新要求覆盖 HLK 与 Attestation 两类签名路径

此次政策适用于所有加入 WHCP 计划，并通过硬件开发者中心（HDC）开发、签署或提交驱动以获取 WHCP 签名的合作伙伴。无论是通过硬件实验室工具包（HLK）认证，还是通过 Attestation 方式签名的驱动，都将受到新规则约束。

微软同时明确，2027 年 3 月之前提交的驱动不需要提供 SBOM 和 VEX；面向 Windows 11 25H2、26H1 以及 Windows Server 2025 之前版本系统的认证要求，也不会加入这两项材料。换言之，新规主要面向未来版本的 Windows 驱动生态，给厂商预留了较长的准备窗口。

• 生效时间：2027 年 3 月起。
• 适用系统：Windows 11 25H2、26H1、Windows Server 2025 及后续版本。
• 必交材料：符合 SPDX 3.0 格式的 SBOM，以及说明已知 CVE 影响情况的 VEX 声明。
• 适用范围：HLK 认证与 Attestation 签名路径均需遵守。

文件规范更细：每个驱动都要单独提供清单

根据微软公布的提交规范，SBOM 和 VEX 文件需要放在驱动程序包目录下的专用子文件夹中，且不能用一套文件覆盖多个驱动。微软所说的单个驱动，是指一个 INF 文件及其对应的一组二进制文件组成的驱动程序包。因此，如果一次提交中包含多个驱动文件夹、每个文件夹又包含多个驱动，就需要为每个驱动分别提供对应的 SBOM 与 VEX。

文件命名也有明确规则：SBOM 文件名称需与 INF 文件对应，采用“<inf_name>.spdx.json”格式；配套 VEX 文件则应命名为“<inf_name>.vex.json”。这些文件不会作为驱动程序包的一部分提供给最终用户，也不应放入补充文档目录。

在技术层面，SBOM 需要采用签名的 SPDX 格式，列出驱动涉及的第一方与第三方组件，包括工具、库、框架和依赖项，并提供准确版本与软件包标识符，以便后续进行漏洞追踪。微软还要求 SBOM 覆盖传递依赖关系，而不仅是直接依赖项；SBOM 与 VEX 声明需要通过 COSE 签名保障完整性。相关 SBOM 至少需保存 10 年，或按欧盟 GPSR 及其他适用法规要求的产品生命周期期限保存，以较长者为准。

影响解读：驱动开发进入“供应链可审计”阶段

从产业角度看，这一变化反映出系统软件安全审核正在从“结果验证”走向“过程与依赖验证”。过去，驱动认证更关注兼容性、稳定性、崩溃率等指标；而引入 SBOM 与 VEX 后，厂商需要清楚说明驱动使用了哪些组件、这些组件是否涉及已知漏洞，以及漏洞是否会在具体产品中形成实际风险。

这对硬件厂商、外设品牌、芯片供应商和驱动外包团队都会带来流程变化。尤其是大量使用第三方库、开源组件或跨团队二进制模块的驱动项目，未来需要更早建立依赖盘点、漏洞响应和合规留档机制。对企业 IT 与安全团队而言，这也有助于在采购和部署 Windows 设备时获得更透明的软件供应链信息。

微软计划在 2026 年 12 月通过新版 Windows 驱动程序工具包（WDK）提供生成和验证 SBOM、生成 VEX 声明所需的工具，并同步发布技术文档。开发商也可以使用第三方或行业标准工具生成相关文件，但最终必须符合 SPDX 3.0 格式。微软建议开发与合规团队提前熟悉 SBOM、VEX 和 SPDX，并整理驱动二进制文件中使用的第三方及开源组件，为 2027 年 3 月之后的新提交做好准备。