Microsoft 安全转型：将问责置于发布速度之上
在反复遭遇安全漏洞、暴露出发布速度与充分防护之间的冲突后，Microsoft 已花费近三年时间，让其安全转型变得可衡量。如今，安全表现会影响员工考核、高管薪酬、产品设计审批、工程流程以及面向客户的默认设置。
该公司将这一计划称为 Secure Future Initiative，简称 SFI。Microsoft 于 2023 年 11 月启动该计划，并在一项联邦审查严厉批评其安全文化后扩大了范围。问题已不再是 Microsoft 能否发布更多安全承诺，而是该公司是否改变了此前让已知风险和老旧系统持续存在的激励机制。
随着 Microsoft 加速发展 AI 业务，这一区别尤为重要。AI 可以发现漏洞、编写检测规则，并关联跨系统的风险；它也可能提高开发速度，并引入行为更难预测的软件。因此，Microsoft 面临一场决定性的考验：当产品团队承受发布新 AI 功能的压力时，安全保障必须保有足够的话语权。
Microsoft 安全转型覆盖每一次绩效考核
Microsoft 正试图让安全成为职业成功的前提，而非员工可以交由专家负责的职责。
据 Cybersecurity Dive 发布的采访报道，Microsoft 的每次绩效考核如今都包含员工对公司及客户安全所作贡献的讨论。这一要求覆盖工程、市场、销售和事件响应等部门。
这一变化让 SFI 的分量超过了又一次内部安全意识宣传活动。晋升、薪酬和职业发展会塑造大型组织内的行为。即便产品按时交付，忽视安全问题的员工如今也将面临个人层面的后果。
Microsoft 此前将许多安全决策置于奖励功能完成的工程流程之中。开发人员可以运行自动化检查、在临近发布时联系安全团队，并寻求最终批准。这一流程将安全视为后期检查点，而非设计约束。
Microsoft Windows Security 企业副总裁 Dana Huang 将旧做法形容为在发布前不久寻求一个勾选项。如今，她的团队会更早介入部分关键领域。在团队仍在决定产品运作方式时，安全工程师即可参与其中。
这种实践通常被称为“左移”。该术语指将安全审查前移至软件开发初期，此时团队仍可在无需重建成品的情况下调整架构。
早期参与也改变了讨论的问题。最终扫描工具能够发现某些编码错误，却未必总能质疑不安全的产品假设。参与设计阶段的安全专家可以审查信任边界、身份要求、数据流、恢复机制和滥用场景。
Microsoft 还成立了网络安全治理委员会。副首席信息安全官代表 Windows、Azure 和 Microsoft 365 等主要业务，定期审查这些组织之间的优先事项和安全权衡。
当交付目标与未解决的风险发生冲突时，该委员会提供升级处理路径。Microsoft 表示，CEO Satya Nadella 已指示管理者将安全置于一切之上。SFI 负责人 Hammad Rajjoub 告诉 Cybersecurity Dive，各团队会定期讨论推迟某一事项，以修复另一项问题。
这一治理结构之所以重要，是因为 Microsoft 的产品共享身份系统、基础设施、开发工具和依赖项。一项服务内部的弱点可能在其他领域造成风险暴露。业务层面的安全负责人比彼此孤立的产品团队更能有效识别这些关联。
该公司报告称，员工对其安全推进工作的支持度平均为 88%。这一数据来自 Microsoft 2026 年 7 月的 SFI 报告，因此属于内部衡量指标，而非独立审计。不过，这表明该计划并未在员工中引发普遍抵触。
支持度并不衡量系统是否安全，而是衡量员工是否认为这场转型有用或可行。这一点很重要，因为当员工将控制措施视为障碍、并寻找非正式绕行方式时，安全计划往往会被削弱。
Microsoft 正押注于问责、治理和员工认同能够相互强化。考核建立个人激励；副 CISO 提供监督；高管指令则在安全团队对发布提出质疑时赋予其权力。
这一组合构成了核心的组织变革。Microsoft 不再将安全描述为在产品开发之外运作的专家职能，而是将安全决策视为每位员工履行日常工作的体现。
多年的安全漏洞让文化变革势在必行
Microsoft 的新控制措施回应的是文化、判断力和透明度方面有据可查的失误，而不只是安全工具的短缺。
SFI 的推出发生在多起破坏性入侵事件之后。LAPSUS$ 网络犯罪组织于 2022 年入侵 Microsoft。2023 年，彼此独立的俄罗斯和中国行动获取了 Microsoft 系统及敏感信息的访问权限。
被追踪为 Storm-0558、与中国政府有关联的组织获得了一枚 Microsoft 签名密钥，并访问了 Exchange Online 账户。受影响目标包括美国政府高级官员，以及参与对华关系事务的机构。
联邦网络安全审查委员会调查了这起事件，并认定其本可避免。其 Exchange Online 审查报告描述了一连串本可避免的错误，并称 Microsoft 的安全文化不足。
该委员会指出，Microsoft 在密钥管理、日志记录、检测、事件响应和公开沟通方面存在弱点；同时还批评 Microsoft 曾就该事件发表后来被证明不准确的说法。
这些发现使问题的严重性超出了传统软件漏洞的范畴。Microsoft 向政府和大型企业提供操作系统、云基础设施、生产力应用、身份服务和安全产品。客户往往同时依赖其中多项服务。
这种集中度赋予 Microsoft 非同寻常的可见性和资源，也带来了关联风险。涉及共享身份或云组件的安全故障，可能影响那些原本认为自己已将风险分散到不同应用中的组织。
因此，审查委员会要求 Microsoft 高级管理层和董事会推动迅速的文化变革，并建议发布一项包含明确时间表的计划，对公司整个产品组合进行改革。
Microsoft 于 2024 年 5 月扩大了 SFI，并承诺落实该委员会的建议。该公司围绕身份、租户、网络、开发系统、威胁检测和漏洞修复来组织工程工作。
它还将高级管理层的部分薪酬与安全表现挂钩。这一决定承认了一个基本的治理问题：如果管理者的衡量标准主要是增长和交付成果，高管就无法可信地将安全称为最高优先事项。
Microsoft 的安全转型如今试图纠正这种失衡。管理者在功能开发与安全修复之间作出选择时，必须考虑正式的安全目标、员工评估、治理审查和高管薪酬。
外部观察人士谨慎地认可了这一变化。Futurum 的 Fernando Montenegro 告诉 Cybersecurity Dive，SFI 似乎正在取得成效。Forrester 分析师 Merritt Maxim 和 Allie Mellen 也称这些改革具有价值。
不过，他们的支持仍附带条件。Mellen 表示，这些变化必须持续嵌入组织并随着时间推移不断改进。Maxim 则警告称，当公众关注消退后，围绕 AI 的紧迫感可能悄然削弱安全纪律。
这一警告指出了真正的压力所在。Microsoft 的安全组织主要竞争的并非另一家供应商的计划，而是 Microsoft 自身对更快产品开发的追求，尤其是在 AI 领域。
该公司已公开经历过这种冲突。其面向 Copilot+ PCs 的 Recall 功能旨在记录活动信息，以便用户检索过去的信息。研究人员对这些记录的存储和保护提出担忧，促使 Microsoft 推迟并重新设计该体验。
Recall 展示了 AI 相关功能如何迅速叠加隐私、身份、存储和访问风险，也说明了安全审查为何必须在产品进入公开预览前启动。
Microsoft 过去的失败使每一项新指标都只能被视为暂时性的。客户需要证据证明，控制措施在旧有服务和新产品中都能稳定运行；当这些控制措施失效时，他们也需要及时披露。
SFI 改变了由谁讨论安全，以及这些讨论在何时进行。安全漏洞解释了 Microsoft 为何必须证明：这些对话会带来不同的工程决策。
监督必须扩展到十几名专家之外
只有当小型安全团队能够在不亲自审查每一行代码的情况下影响数千项工程决策时，这一新的治理模式才会成功。
Windows 展现了规模化挑战。Huang 告诉 Cybersecurity Dive，该部门约有 7,000 名员工，其中约 5,000 名为工程师。她的 Windows 安全工程团队则大约只有十几人。
十几名专家无法手动检查 5,000 名工程师产出的所有内容。试图采用这种模式会造成延误，同时鼓励产品团队将安全视为他人的工作。
Montenegro 认为，安全团队应当建立由开发团队继承的标准、工具和安全默认设置。这一模式通过每位工程师使用的系统，传播小团队的专业知识。
安全默认设置是指无需用户或开发人员主动启用保护措施，便能提供更安全行为的配置。它们减少了部署过程中对完美决策的依赖。
Microsoft 已将这一原则应用于内部开发流程。其 2026 年 7 月的 SFI 进展报告称，工程默认设置如今可阻止 83% 的流水线访问未经批准的软件包端点。
这一控制措施针对软件供应链风险。遭到入侵或被误选的外部软件包，可能将恶意代码引入受信任产品。限制软件包来源可减少此类故障发生的机会。
同一份报告称，抗钓鱼多因素身份验证保护了 99.97% 的 Microsoft 用户与设备配对。抗钓鱼身份验证采用旨在防止攻击者在欺诈网站上重放凭据的方法。
微软还表示，其已撤销对超过 732,000 项资源的公共访问权限。网络隔离已扩展至 100 万项资源，公司还停用了 140 万个未使用的应用程序。
未使用的应用程序和暴露的资源会扩大攻击面，也就是攻击者可瞄准的系统集合。移除它们可减少被盗凭据、遗忘的权限和存在漏洞的服务成为入侵入口的机会。
据微软称，跨边界凭据隔离覆盖率已达到 98.7%。这一控制措施旨在防止某一环境或信任区域中的凭据在另一环境中变得可用。
这些衡量指标比泛泛承诺改善文化更具信息价值。它们明确了具体控制措施的覆盖对象，并展示了微软所称部署保护措施的广泛程度。
不过，这些百分比也暴露了尚未完成的工作。在极其庞大的环境中，即使某项控制措施覆盖了 99%，仍可能留下实质性风险暴露。攻击者会寻找例外情况，因为一个被忽略的身份或遗留系统就可能提供立足点。
这些指标无法独立证明微软是否选择了正确的分母。它们也没有显示控制措施失效的频率、例外情况的关闭速度，或对手绕过这些措施的有效程度。
因此，独立验证仍然至关重要。客户应关注事件发生频率、可利用性、披露质量和修复速度。这些结果能够揭示内部覆盖率统计是否真正转化为更低的外部风险。
微软还可以衡量漏洞在哪个阶段被发现。若能在发布前发现更多严重缺陷，将支持其“左移”策略；若这些问题反复在生产环境中出现，则说明设计审查和自动化关卡仍不完善。
平均修复时间是另一项有用指标。它衡量团队遏制或修复已确认问题所需的时间。仅看平均值可能掩盖严重的异常值，因此微软还应披露其最高风险案例的表现。
大规模监督最终要求产品团队对自身风险负责。安全专家可以定义架构、维护关卡并审查例外案例，但无法取代每一位构建 Windows、Azure 或 Microsoft 365 的工程师所作的判断。
绩效评估要求支持这一模式。它告诉开发人员，使用中央安全控制措施是其工作的一部分；也告诉管理者，绕过这些控制措施是一项会受到审查的领导决策。
这正是问责与工程实践交汇之处。文化变革为团队采用标准提供动力，技术默认设置则让更安全的决策更容易在大型组织中反复执行。
AI 扫描发现成熟代码审查遗漏的风险
微软正利用 AI 扩大安全覆盖范围，但这项技术是专家审查的放大器，而非替代品。
微软推出了 MDASH，这是一款多模型智能体扫描器，可检查源代码中的漏洞。智能体系统能够规划并执行多个相互关联的分析步骤，而非仅生成一次孤立的模型响应。
微软称，MDASH 在 Windows 组件中发现了严重的远程代码执行漏洞，包括其 TCP/IP 网络堆栈。远程代码执行允许攻击者在存在漏洞的条件下，在另一台系统上运行软件。
这一发现挑战了成熟工程组织中一种常见的假设。开发人员原本认为相关代码是稳定的，因为团队多年来一直在审计和运行这些代码。
微软安全研究副总裁 Taesoo Kim 表示，开发人员最初对这些发现表示怀疑。据该公司称，微软随后调查并修复了这些漏洞。
MDASH 扫描微软正在开发的代码，以及接近发布的软件。Rajjoub 表示，强制执行机制可以阻止产品发货，直至代码达到所要求的安全标准。
微软还将该扫描器应用于开源依赖项，包括 Linux 内核和 FFmpeg。这些项目受到广泛的公开审查，但其规模和复杂性仍为细微漏洞留下空间。
该公司已开始向客户提供这项扫描技术。这一商业举措带来了额外的考验：微软必须证明 MDASH 能够在其自身环境之外的代码库中产出有价值的发现。
7 月报告描述了一个更广泛的多智能体评估系统。微软称，该系统分析源代码、身份配置、网络拓扑和运行时状态，以识别复合漏洞。
当多个单独看来影响有限的弱点共同构成危险攻击路径时，便会形成复合漏洞。宽松的身份设置、可访问的网络端点和编码错误，可能只有在结合审视时才会变得至关重要。
传统扫描器往往一次只分析一个层面。将架构与运行时上下文关联起来，可帮助团队优先处理攻击者可能实际组合利用的发现。
微软称，其安全工程师确认了该系统超过 90% 的发现。这是一个令人鼓舞的内部结果，但该公司尚未提供足够的公开细节以供独立复现。
读者不应将这一数字解读为普适的准确率。结果取决于接受测试的服务、确认的定义，以及纳入计算的发现。
AI 辅助扫描还带来了新的运营挑战。只有团队能够验证并修复更多发现的漏洞时，发现更多漏洞才有价值。快速扩大的待处理队列可能压垮工程师，或导致流于表面的修复。
误报仍然代价高昂，因为专家必须对其进行调查。漏报则更危险，因为团队可能误以为扫描已确认代码安全无虞。
因此，人工审查仍然处于核心位置。安全工程师必须验证可利用性、理解架构后果，并决定某项修复是否会引入另一个问题。AI 可以扩大他们的搜索能力，但不应承担最终风险决策。
微软称，其在 2026 年新增了超过 100 项检测能力，使总数超过 350 项。该公司正从基于特征的检测转向行为和基线分析。
特征检测会搜索已知的恶意模式。基于行为的检测则寻找偏离预期运行状态的可疑活动，这有助于发现不熟悉的攻击。
微软的安全转型在开发生命周期的两端使用 AI。模型在发布前搜索代码，检测能力则在部署后监控系统。人类决定如何响应由此产生的信号。
这一安排反映出一种务实的权衡。仅靠人工审查无法跟上微软的代码规模；仅靠 AI 也无法提供问责、情境判断或可靠保障。
MDASH 最有力的证据，不会是它生成的发现数量，而是微软在客户遭遇这些问题之前消除的严重漏洞所占比例。
安全默认设置将部分成本转移给客户
更安全的默认设置可减少可预防的风险暴露，但也可能扰乱既有工作流程，并将实施工作转移给微软客户。
微软已将客户此前可以选择跳过的保护措施设为强制要求。Azure 于 2024 年 10 月开始分阶段要求使用多因素身份验证。
多因素身份验证要求在授予访问权限前提供不止一种形式的证明。它降低了被盗密码的价值，但保护效果因身份验证方式而异。
微软错开了 Azure 的推广节奏，因为立即强制实施可能会破坏客户工作流程。新账户首先面临这一要求，而现有环境则获得了过渡时间。
这一决定揭示了安全与速度冲突的第二层面。微软有时必须给客户带来不便，才能移除不安全的配置。延后要求可以维持连续性，但也会延长脆弱做法仍有可能存在的时期。
该公司还默认禁用了一些高风险功能。客户在具备特定需求和适当防护措施时，可以启用选定功能。
这一做法颠覆了长期以来的软件习惯。供应商往往会启用功能，以让产品显得完整且易于采用。每项活跃服务、协议或集成都可能形成另一条需要保护的路径。
默认安全的产品会在管理员作出任何选择前减少这种风险暴露。它也能帮助缺乏专业人员、无法评估每项技术设置的小型组织。
不过，默认设置并不能消除客户责任。组织仍可能通过例外设置、过度权限、未受管理的设备或不佳的恢复程序削弱保护。
微软在企业技术领域的集中度，使这些默认设置的设计尤为重要。更安全的 Azure 或 Microsoft 365 设置可以同时降低许多组织的风险；有缺陷的设置同样可能广泛传播风险暴露。
客户应询问新的默认设置是否适用于现有租户，而不仅限于新部署。他们还应审查豁免是否会到期，以及管理员能否集中识别偏差。
微软更改控制措施时，透明度至关重要。管理员需要获得足够提前通知，以更新自动化流程、测试依赖项并说明运营影响。沟通不足可能会使合理的安全要求演变为可用性事件。
微软称，其客户安全管理办公室现已使用既定操作手册，在重大事件期间协调沟通。其更新后的 SFI 材料还描述了通过行业标准发布云漏洞信息的做法。
公司在其 SFI expansion 中承诺加快缓解措施并提供更清晰的公开信息。这些承诺直接回应了 Storm-0558 入侵事件后的批评。
然而，披露仍是最难从内部判断的结果之一。公司可以控制何时宣布事件、如何描述影响范围，以及发布哪些技术细节。
网络安全审查委员会批评了微软早期的公开声明，因为调查期间的重要解释发生了变化。这段历史提高了未来事件沟通的标准。
因此，客户应区分预防指标与信任指标。身份验证覆盖率和资源隔离衡量已部署的控制措施；快速、准确且完整的披露，则衡量微软在这些控制措施失效后如何行动。
持续发现严重漏洞也使任何胜利宣言都无法成立。Cybersecurity Dive 报道称，在其 2026 年 9 月文章发布前的五个月内，至少披露了五个严重的 SharePoint 漏洞。
频繁披露可能意味着研究人员和内部工具正更有效地发现问题，也可能表明持续存在工程薄弱环节。具体背景、利用状态、受影响配置和修复时间决定了哪种解读更有说服力。
微软的规模必然会带来持续的漏洞报告。任何可信的转型都无法承诺消除缺陷。相关检验在于，严重失误是否变得更难预防、更具破坏性，且处理得更不透明。
安全默认设置有助于遏制常见错误，但无法取代严谨的设计、准确的资产清单、受控的身份体系和有效的事件响应。
对于企业买家而言，实际问题在于：Microsoft 的控制措施能否在不制造隐性依赖的前提下，降低其总体风险敞口。答案会因遗留系统、云服务和受监管环境而异。
下一轮证据必须来自实际结果
Microsoft 安全转型的下一阶段需要独立可观察的结果，而不是更多内部进展百分比。
首先应关注的是发布前发现能力。Microsoft 应证明，AI 扫描和早期设计评审能够在产品交付客户前发现越来越多的关键漏洞。
这一指标将把 MDASH 和左移式安全监督与直接的工程结果联系起来。若该比例下降，将削弱 Microsoft 关于新工具和治理机制能够更早预防故障的论点。
第二个信号是针对高严重性云漏洞的修复表现。Microsoft 现有材料称，其缓解措施速度有所提升，其中一个正被 активно利用的客户端问题在一天内得到处理。
单一案例不足以证明存在一致的运营标准。买家需要看到分布数据、严重性分类和例外数量。修复时间的持续缩短，才能支持问责机制已经改变执行方式这一说法。
第三个信号是 Microsoft 如何处理下一起重大事件。公司必须及时发现事件，准确界定受影响系统，迅速通知客户，并在不反复修正的情况下解释根本原因。
任何内部情绪评分都无法替代这项考验。清晰的应对将增强外界对 Microsoft 治理改革的信任。另一起本可避免的漏洞事件，加上不完整的解释，则会削弱该计划的核心承诺。
AI 将令这三个信号都承受压力。它帮助 Microsoft 审查更多代码并关联更多遥测数据；同时，它也帮助产品团队更快开发，并为攻击者提供发现和组合弱点的工具。
Forrester 的警告值得重视。围绕 AI 的紧迫感可能悄然侵蚀安全纪律，尤其是在竞争性期限再次出现、公众关注转移到其他地方时。
Microsoft 的安全委员会和绩效激励机制旨在抵御这一循环。其有效性将在高级产品团队因安全负责人反对而接受延期、重新设计或缩减功能范围时显现。
客户很少能看到每一项内部决策，但仍可通过发布说明、事件报告、漏洞记录、默认配置以及修复已被利用漏洞所需的时间来评估结果。
采购 Microsoft 服务的安全团队也应保留独立控制措施。他们应维持自己的身份监控、资产清单、恢复计划、网络分段和供应商风险评估。
供应商改善并不会消除集中度风险。组织仍需了解哪些关键流程依赖于单一身份提供商、云平台或管理界面。
尽管如此，Microsoft 的 SFI 为其他大型企业提供了一个有益的模型。当评审、薪酬、产品架构、开发门槛和客户默认设置都指向同一目标时，安全就更具可信度。
该模型也说明，AI 安全是一个组织问题。扫描器可以识别可疑代码，但无法决定由哪位高管接受延期；它无法确保员工提出疑虑，也无法保证对外披露准确无误。
问责机制提供了缺失的这一层。即使 AI 产出了支持决策的证据，人类仍保有决策的责任。
Microsoft 的安全转型已经超越口号，因为该公司改变了激励机制并部署了可衡量的控制措施。但它尚未赢得永久性的定论。
决定性证据将通过日常运营出现：更少可预防的故障、更快的修复、更清晰的披露，以及在 AI 发布竞赛中可见的克制。
对于技术领导者而言，下一步是将 Microsoft 报告的控制措施与自身环境中的条件进行比较。还存在哪些例外？谁对此负责？哪些证据能够传达给高管？这些问题能将一次信息更新转化为实际的风险审查。
请继续通过漏洞结果、修复时间和事件透明度关注 Microsoft 的安全转型。如果这些指标同步改善，说明 Microsoft 的治理变革正在发挥作用；如果交付压力削弱其中任一项，旧有矛盾只不过被重新组织了。
