摘要

  • 网络安全隐患审查委员会要求微软首席执行官与董事会公开一份带具体时间表的整改计划。微软给出了带日期的进度报告、分档目标、具名高管和薪酬挂钩，但这些文件都不足以让第三方复算它公布的百分比。
  • 发布管道覆盖率从 2025 年 11 月的 94% 降到 2026 年 7 月的 90%，微软把这一变化解释为统计口径扩大。一个跟着自己分母一起移动的数字不构成保证，可它正是以这种形态进入采购文件的。

网络安全隐患审查委员会的《2023 年夏季 Exchange Online 入侵事件审查报告》——本次查阅的副本封面日期为 2024 年 3 月 20 日——核心诉求都压在第一条建议里：「The CEO and Board should develop, and share publicly, a plan with specific timelines to make fundamental, security-focused reforms」（CSRB 报告，印刷版第 19 页）。

这份工具要同时满足三个条件。它指向公司最高层，而不是某个工程团队；它要求具体时间表，而不是一个正在推进的项目；它要求公开，也就是要求有一个能做出判断的读者。三条中只占两条，不等于三条都占。

2024 年 5 月 3 日，微软用一组 100% 的工程目标作答，其中一条是：「100% of access to source code and engineering systems infrastructure is secured through Zero Trust and least-privilege access policies.」（2024 年 5 月 3 日公告）达标情况以目标和关键结果衡量。但就公布出来的这一页看，这些目标没有各自的日历期限，也没有为每一条指定负责人。

方法写在 2025 年 4 月报告里，一点不含糊：「We calculated progress by recording the completed percentage of standards and key results, those defined initially and any additions.」（2025 年 4 月报告，印刷版第 4 页）换成操作语言：公司往里加活，分母就跟着涨。这不是作弊，这是一个定义——而正是这个定义让外部读者无法把它当作进度证据。

结果按档发布，不给点值。2025 年 4 月，目标 1 至 3 落在 95–99% 档，目标 4、5 落在 66–94% 档。2025 年 11 月，目标 2、3 仍在 95–99%，目标 1、4、5 降到 66–94%，公司给出的理由是资产清单范围扩大（2025 年 11 月报告）。2026 年 7 月，目标 1 记为「closed」，目标 2、3 在 95–99%，目标 4、5 在 66–94%（2026 年 7 月报告）。档位不是计数，结项也不是资产比例：两者都复算不出来。

覆盖率数字倒是带日期、可对比的——前提是尊重每份报告的统计范围。2024 年 9 月：商业云生产构建管道中有 85% 使用中央统管的管道模板（2024 年 9 月报告）。2025 年 4 月：构建管道 92%、发布管道 54%，代码签名权限限制在生产租户身份的比例为 56%。2025 年 11 月：发布管道使用统管模板的比率为 94%，网络隔离为 89%。2026 年 7 月：关键与高价值构建管道 93%，发布管道 90%（2026 年 7 月信任中心汇总页）。

发布管道这一串值得慢读：54%，然后 94%，然后 90%。微软对最后一次变动的说法是：「Recent metric variation reflects expanded measurement scope, with final attribution under review.」（2026 年 7 月 PDF）想知道控制是退步、进步还是仅仅被重新定义的人，在文件里找不到答案。公司自己写着，归因仍在复核之中。

被引用最多的是另一个性质的数字：「achieving 99.5% detection and remediation of live secrets in code.」（2025 年 11 月 10 日公告）文件没有给分子、没有给分母、没有给抽样方法，也没说明这衡量的是覆盖率、检出性能还是修复完成度。这是公司对自己的陈述，不是经过验证的准确率。

2026 年 7 月公布的数量同样需要谨慎对待：已修复超过 550,000 个关键与高风险开源漏洞实例，自动化容器补丁每月处理约 300 万个漏洞实例（2026 年 7 月汇总页）。实例不是唯一漏洞，也不是 CVE；550,000 这个数字没有给出统计窗口；每月吞吐量不等于清空积压。另有两条数据界定读法：受监控的管道约 80,000 条；截至 2025 年 4 月，七大类安全日志中有五类达到留存标准（2025 年 4 月报告）。各期报告的统计期间也并不一致：2025 年 11 月按 2025 年 1 月以来统计 CVE，而漏洞赏金支付覆盖的是 2024 年 7 月至 2025 年 6 月。发布日期不是统一的结算日。

公司自己也承认这条边界：「We do not disclose the full body of work we are undertaking to advance an objective (such as standards and key results)」（2025 年 11 月报告）。这是坦白。也正是仅凭这些文件，任何外部审计都无法重做那套计算的技术原因。

剩下最像后果的一条。Satya Nadella 在 2024 年 5 月说，微软正在「basing part of the compensation of the senior leadership team on our progress towards meeting our security plans and milestones」（2024 年 5 月 3 日官方博客），2024 年 9 月又说了一遍：「Microsoft’s senior leadership team now has security performance directly linked to compensation.」（2024 年 9 月进度更新）本次查阅的文件里，没有一份公布权重、触发阈值，或与某一具体里程碑挂钩的自动扣减。有薪酬挂钩而无标尺，仍只是优先级信号，不是可执行条款。

治理结构也是有名字的。CISO Igor Tsyganskiy 领导由 Deputy CISO 组成的网络安全治理委员会；Deputy CISO 与工程团队共同承担监督、风险管理和汇报责任；高管评审每周一次，董事会更新每季度一次，安全绩效纳入员工考核。Joy Chik 被列为该项目的 executive sponsor（2024 年 9 月公告）。具名的监督机制，不等于一份为每个指标指定负责人和日期的登记表。

也要如实记下确实存在的部分。该项目至少有一个日历期限：目标是在 2029 年前让关键产品和服务过渡到后量子密码学（PQC）（2026 年 7 月 10 日公告）。说它全无日期，是错的。另外，2025 年 4 月报告的附录把 CSRB 建议 1 至 4 标注为「complete」——那是微软对自己合规情况的评估，不是独立验证。

项目主页上列出的最新一期是 2026 年 7 月，配套公告日期为 2026 年 7 月 10 日（信任中心项目主页）。节奏是承诺，不是时间表：「We plan to keep ourselves accountable and provide the latest SFI news to customers, partners, and the security community through regular updates.」页面上没有固定的发布周期，而这个页面本身随时可改。

至于那个决定一切的问题——除了微软自己，还有谁为这些百分比背书——诚实的回答很窄：在我按标注查阅日期读过的十一份文件里，没有出现对已公布百分比的独立鉴证。这十一份包括 CSRB 报告、四份详细进度报告、四篇带日期的微软公告、2026 年 7 月的信任中心汇总页，以及项目主页。内部测试、标准映射和委员会早前的入侵审查，都不构成对后续进度数字的独立保证。这批文件里没有，不等于别处一定没有。

与本报此前对这家公司的报道相比，这里新增了什么，值得说清楚。我们过去的七篇报道把它当作产品与市场参与者：Copilot 业务整合（2026 年 3 月 19 日）、据报道的 Microsoft 与 Amazon、OpenAI 之间的博弈（2026 年 3 月 19 日）、Stryker 入侵事件后 CISA 针对 Intune 管理员控制项的警示（2026 年 3 月 19 日）、Microsoft 365 服务中断（2026 年 1 月 23 日）、与 G42 在阿联酋的 200 兆瓦扩建（2025 年 11 月 7 日），以及英国竞争与市场管理局关于云市场的建议（2025 年 8 月 1 日）。没有一篇检验外部审查之后、可执行的补救被什么替代了。我们此前关于该委员会本身「无强制力」的简报，止步之处正是本文的起点：公司用它自己造的那套东西顶上了。BTW 名录中的 Microsoft Corporation 条目在这里只是身份坐标，不作为运营事实来源。

所以真正有价值的问题不是微软有没有认真做事——文件显示有工作、有具名的人、有几万条被纳管的管道。问题是：一个自己发布的百分比，究竟构成了什么义务。写进采购合同，完成度百分比看着像保证；写进年报，它看着像控制；写进保单，它看着像被度量过的风险。三种情形里，读者买下的都是一个只有卖方能出具的结论。由被测量者自己定义、自己计算、自己解释的度量，不是验证，是带着小数点的自我评估。