2026年9月2日，微软在一条几乎不被注意的公告中，为全球数十万Windows驱动开发者划下了一条红线：从2027年3月起，所有面向Windows 11 25H2/26H1和Windows Server 2025新提交的驱动程序，必须附带SPDX 3.0格式的SBOM（软件物料清单）和VEX（漏洞可利用性交换）声明。没有这两份文件，或者文件未能通过微软的验证，驱动程序就拿不到WHCP签名——而这套签名，是驱动能在Windows上加载和运行的门票。
这不是一个孤立的政策更新。它是一张多米诺骨牌。在它之前倒下的牌包括：2021年SolarWinds攻击引发的美国总统网络安全行政令、2024年欧盟《网络韧性法案》（CRA）的正式通过、以及2025年以来全球主要科技监管机构对软件供应链透明度的轮番施压。在它之后，将有更多牌倒下——更多的操作系统平台、更多的硬件生态、更多的开发者。
一张成分表，和一张漏洞声明
SBOM，Software Bill of Materials，软件物料清单，本质上是软件的“成分表”。一份规范的SBOM会列出软件产品中使用的每一个第三方组件、开源库、依赖包及其版本号。当Log4j这样的漏洞爆发时，有了SBOM，安全团队可以在几分钟内排查出哪些产品受影响，而不是花几周逆向拆解。
VEX（Vulnerability Exploitability Exchange）则是SBOM的补丁：它不列出所有组件，而是明确告诉下游——这个漏洞对我们的产品“有没有影响”、“为什么没有影响”、“是否已修复”。SBOM回答“我用了什么”，VEX回答“我知道有什么漏洞，但哪些真的危险”。
微软要求驱动开发者同时提交这两份文件，并采用SPDX 3.0格式。SPDX 3.0是Linux基金会维护的SBOM标准的最新大版本，其前身SPDX 2.2.1于2021年被采纳为ISO/IEC 5962:2021国际标准。相比2.3版本，SPDX 3.0最重要的变化之一是把VEX信息“内嵌”进SBOM的结构中，不再作为两份独立文档管理。这意味着微软要求的不是“提供一份SBOM”，而是“提供一份内置完整安全评估的高质量SBOM”——门槛比行业普遍做法高出至少一个层级。
从最佳实践到强制门槛
SBOM这个概念在软件行业存在多年。2021年5月拜登签署的EO 14028行政令，首次要求所有向美国政府销售软件的供应商提供SBOM。此后，各大科技公司纷纷建立内部SBOM能力。微软自己在2023年开源了SBOM工具，并在内部实现了每次构建自动生成SBOM。谷歌、AWS、Oracle也都有类似动作。
但在驱动生态中，SBOM从未被强制。驱动——尤其是内核模式驱动——是Windows安全攻击面中最敏感的一层。一个存在漏洞的内核驱动可以让攻击者直接获得系统最高权限。历史上，Stuxnet利用的就是驱动程序签名校验机制的缺陷；2021年的SolarWinds攻击虽与驱动无关，但它教会全球安全社区一个残酷教训：供应链上的每一个环节都可能成为突破口。
WHCP（Windows Hardware Compatibility Program）是微软对驱动进行官方签名的唯一通道。没有WHCP签名，新版Windows系统将默认拒绝加载该驱动。将SBOM和VEX作为WHCP的前置条件，意味着“没有供应链透明度→无法签名→驱动无法运行”——一条铁链。
这条铁链的锻造者不只是微软。欧盟《网络韧性法案》于2024年11月20日在官方公报发布，2024年12月10日正式生效，设定了2027年12月11日的全面合规截止日。CRA明确要求所有“含数字元素的产品”的制造商必须维护SBOM。微软提前9个月启动驱动SBOM强制，一方面是在为自家生态提前排雷，另一方面也是在向硬件合作伙伴发出信号——CRA不是远在天边的欧盟文件，它已经写进了微软的开发者文档。
谁的锅最重
受影响最直接的，是那些通过硬件开发者中心（HDC）提交驱动认证的硬件厂商和开发者。
对大型硬件厂商——英特尔、AMD、英伟达、Realtek、联发科、博通等——这些公司已有一定程度的软件供应链管理能力。但挑战在于规模：一家主流芯片厂商可能同时维护数百个驱动程序，每个驱动依赖数十到数百个第三方组件。为整个驱动矩阵生成规范化的SPDX 3.0 SBOM，并将VEX信息嵌入其中，需要改造现存的CI/CD构建流水线。
对中小型驱动开发者——那些为工控设备、医疗仪器、专用外设编写驱动的小团队——冲击更大。这些团队通常没有专职的软件供应链安全工程师，对SPDX、VEX、SBOM这些词汇可能只是略有耳闻。微软计划在2026年12月发布新版WDK，增加SBOM生成与验证功能，但留给这些开发者的学习窗口只有3个月——从工具发布到新规生效。
还有一类受损方是遗留驱动的维护者。那些面向Windows 11 25H2/26H1新提交通道的旧驱动，即使代码改动极小，也必须附带完整的SBOM和VEX。这意味着在一个修一行代码的简单更新里，驱动开发者可能要多花两天去梳理整个依赖树。
SPDX 3.0的飞跃与挑战
微软选定的SPDX 3.0格式本身也在经历重大升级。SPDX 3.0将标准全称从“Software Package Data Exchange”改为“System Package Data Exchange”——一字之差，范围从单一软件包扩展至整个系统，包含数据集、AI模型、构建信息等。它引入了Profile（配置文件）机制，允许不同用例只选取自己需要的部分：软件Profile、安全Profile、许可Profile、构建Profile、AI Profile等。
对驱动开发者来说，最核心的是安全Profile。它允许将VEX状态判断直接嵌入SBOM，用标准化的关系类型描述某个组件是否受某个CVE影响、影响程度如何、是否已修复。SBOM不再是一份静态清单，而是与安全信息实时关联的可更新活文档。
但挑战也很现实。SPDX 3.0.1稳定版于2024年12月发布，但工具链的成熟度参差不齐。微软的sbom-tool虽已支持SPDX 3.0输出，但社区反馈显示其处理大规模多Profile文档时仍有性能瓶颈。WDK的新功能能否填补这些缺口，将是驱动开发者2026年12月最关注的问题。
监管的收敛：从华盛顿到布鲁塞尔
把这次动作放在更大的图景中看，它是全球软件供应链安全监管加速收敛的标志性事件。
美国的路径：2021年EO 14028行政令→NIST发布SSDF安全软件开发框架→OMB要求联邦供应商自证合规→各大科技公司自行建设SBOM能力。欧盟的路径：2022年CRA提案→2024年正式通过→2027年12月全面执行→SBOM成为法律强制要求。中国的路径：2021年《网络产品安全漏洞管理规定》→2024年《网络数据安全管理条例》→关键信息基础设施供应链安全持续强化。
微软作为业务横跨所有主要市场的全球科技巨头，需要在三条监管路径的交汇处找到统一的合规方案。驱动SBOM强制，就是这套方案中最具体的一块拼图。它在技术层面兼容美国EO精神，在时间线层面与欧盟CRA对齐，在方法论层面遵循SPDX这一ISO衍生标准。三线合一，一套打法。
更进一步看，这不会是微软的终点。一旦驱动SBOM机制在WHCP中落地验证，同样的逻辑完全可以推广到其他Windows组件提交——包括应用层软件、系统更新、甚至Azure上的容器镜像。
18个月倒计时
对Windows驱动开发者来说，从现在到2027年3月，只有18个月。这个窗口看起来充裕，但考虑到SPDX 3.0工具链的学习成本、驱动依赖树的梳理工作量、以及CI/CD改造周期，真正可用的时间远没有那么宽裕。
至少有三件事现在就可以做：第一，评估所有驱动项目的第三方组件依赖情况，建立基线清单；第二，熟悉SPDX 3.0规范，特别是安全Profile和VEX处理方式；第三，关注微软2026年12月的WDK更新，第一时间在新版工具上跑通SBOM生成和验证流程。
而那些尚未涉足欧盟市场的硬件厂商更要注意：CRA的执行范围并不严格区分销售渠道，只要最终用户位于欧盟境内，制造商就可能被追责。驱动SBOM合规，不是可选项。
SBOM从一句口号变成一行代码，从一份白皮书变成一个强制字段，用了五年。驱动开发者是第一批被推入新规则的人，但他们不会是最后一批。供应链透明化的浪潮已经涨到了脚踝，而微软刚刚打开了闸门。
当每一个Windows驱动都附带了一份SPDX 3.0 SBOM，整个PC生态的安全基线将被重新定义。到那时，再回头看2026年9月2日的这条公告——它不只是驱动签名的规则变动，更是全球最大规模的操作系统，在第二个十年的末尾，向供应链安全交出的一份明确答卷。
快报