北京
微软给Windows驱动生态上了一道新锁。从2027年3月起，所有面向Windows 11 25H2、26H1及Windows Server 2025及后续版本的驱动提交，必须附带软件物料清单（SBOM）和漏洞可利用性信息交换（VEX）声明，缺一样，微软就不给签。
这项调整属于Windows硬件兼容性计划（WHCP）政策的一部分。微软在当地时间9月2日发布公告，明确这次收紧的核心目的：提高Windows驱动生态的安全性与完整性，同时满足欧盟《网络韧性法案》（CRA）的合规要求。背后有监管压力在推，并非微软单方面的决定。
新规到底卡在哪？
从2027年3月开始，驱动提交必须包含符合SPDX 3.0格式的SBOM，以及用于说明该驱动是否受到已知CVE漏洞影响的VEX声明。如果提交内容缺少这两份文件，或者文件未通过验证，微软将直接拒绝提供WHCP签名。新要求同时适用于通过硬件实验室工具包（HLK）认证以及通过Attestation方式签名的驱动。
2027年3月之前提交的驱动不受影响，针对Windows 11 25H2、26H1及Windows Server 2025之前版本的Windows系统，认证要求同样不包含这两项材料。这是一条面向未来的硬性门槛，不是追溯性惩罚。
文件怎么交？规则比你想的细
微软公布的提交规范里，有几个细节值得注意：
- SBOM和VEX文件需要放置在驱动程序包目录下的专用子文件夹中，不能放进补充文档目录
- 每个驱动都必须分别提供一份SBOM和一份VEX声明，不能用一套文件覆盖包含多个驱动的整个提交内容
- 单个驱动的定义是：一个INF文件及其对应的一组二进制文件组成的驱动程序包
- 如果提交中包含N个驱动文件夹、每个文件夹包含M个驱动，就需要提供N×M份独立的SBOM和VEX文件
文件命名也有硬性规定。SBOM文件名称需要与INF文件名称对应，格式为“.spdx.json”；配套VEX文件命名为“.vex.json”。这些文件不会作为驱动程序包的一部分提供给最终用户。
技术要求：不只是交个文件那么简单
SBOM需要采用签名的SPDX格式，列出驱动涉及的第一方和第三方组件，包括工具、库、框架及依赖项，同时提供准确的版本和软件包标识符，以便进行漏洞追踪。这里有个容易踩坑的点：SBOM必须包含传递依赖关系，而不只是直接依赖项。很多开发团队只梳理了直接引用的库，忽略了那些间接引入的组件，到时候验证会直接卡住。
SBOM和VEX声明需要通过COSE签名保障完整性。相关SBOM至少需要保存10年，或者按照欧盟GPSR及其他适用法规要求的产品生命周期期限保存，以较长者为准。这意味着驱动开发商需要建立长期的文件留存机制，不是提交完就完事了。
工具时间线：2026年12月是关键节点
微软计划在2026年12月通过新版Windows驱动程序工具包（WDK）提供生成和验证SBOM、生成VEX声明所需的工具，并同步发布相关技术文档。开发商也可以使用第三方或行业标准工具生成这两份文件，但最终文件必须严格符合SPDX 3.0格式。
微软同时提醒，现有工具可用于提前熟悉相关流程，但2026年12月发布的新工具将取代当前版本。现在想练手可以，但别把现有工具当最终方案。
给开发团队的建议：现在就该动起来
微软建议开发和合规团队提前了解SBOM、VEX及SPDX格式，并开始整理驱动二进制文件中使用的第三方和开源组件。这个建议听起来温和，实际操作起来工作量不小——很多老驱动的依赖关系早就没人说得清了，现在不梳理，2027年3月提交窗口打开时会非常被动。
这次政策调整适用于所有加入WHCP计划，并通过硬件开发者中心（HDC）开发、签署或提交驱动以获取WHCP签名的合作伙伴。如果企业计划在2027年3月之后为上述系统提交驱动，新要求就是绕不开的硬约束。
简单算一笔账：一个驱动包里有10个驱动，就需要准备20份独立文件（10份SBOM + 10份VEX），每份都要符合SPDX 3.0格式、通过COSE签名、包含完整的传递依赖信息。这不是临时抱佛脚能搞定的工作量，提前规划是唯一出路。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
