安全是微软所有产品的关键组成部分。强大的安全重点从我们所有工作的开始就得到强调，包括在设计过程中进行威胁建模，并考虑苹果自身对其平台上产品的安全建议。作为这种方法的一个例子，我想分享一些我们为保护Mac Office 2016所做的工作。

对于Mac Office 2016和Office 365订阅系统，我们保持工具系统的“常青”。通过Mac Office 2016，我们每月发布一次更新，并在Xcode及其内部工具发布时测试并采用最新版本。我们通过广泛的自动化测试来减轻编译器变更的风险。我们拥有一个由数百台Mac Mini组成的农场，每天运行数万个基于场景的测试，并调查自动化系统报告的每一个失败或意外行为变化。

我们尽可能通过代码静态分析来增强自动化场景测试，并包括使用故意损坏的文件和数据进行的输入模糊测试，以识别代码中的不当预期。在整个Office中，我们正在投资更智能的模糊测试工具，并持续运行它们。这推动了更好的数据验证，特别是在旧代码中，并使应用程序更加稳定和安全。

通过使用最新的工具链，我们从编译器改进中获得安全好处。这些更新不断带来新的代码警告；我们默认启用所有警告，并将警告视为错误。这随着每个新编译器的发布提高了我们的代码质量。并非所有编译器警告都意味着安全问题，但那些确实触发错误的问题我们会立即修复。我们还在每个版本中寻找新的可选编译器安全功能（如-fstack-protector和-D_FORTIFY_SOURCE=2）并启用它们。工具链更新带来了新的macOS和iOS SDK，其中包含新API以及操作系统中已弃用或不安全API的注释。我们认真对待这些注释，并更新我们的代码以移除后者的使用。

Xcode 7引入了一个名为地址消毒器（ASan）的新工具。该工具可以帮助识别具有潜在安全影响的错误，但它比非ASan构建需要更多内存，并且对于大型32位应用程序不实用。Mac Office 2016现在是64位的，我们每天生成一个内部ASan检测构建，并通过与常规产品相同的自动化测试运行它。自动化系统发现的任何ASan问题都会成为要调查和解决的错误报告。

我们还进行了超出新工具链或64位转换强制要求的代码变更的安全改进。我们重新设计了Office套件，仅在必要时使用受限的可执行内存页面，并维护一个被认为本质上不安全或允许不安全编码实践的API黑名单。我们定期审计代码库，以确保不使用这些API。我们还启用了位置无关执行来构建我们的应用程序。通过该标志、我们支持的最低操作系统10.10，以及我们所有Mac Office应用程序现在都是64位的事实，macOS可以将地址空间布局随机化应用到我们的应用程序中，作为另一层防御。

尽管对于macOS应用程序是可选的，我们也为我们的应用程序启用了macOS沙箱。选择加入沙箱为我们评估的几乎每一个威胁增加了另一个障碍，使利用更加困难。我们认为这是Mac应用程序的最佳实践。沙箱改变了应用程序与操作系统的交互方式，要求我们重新审视几个现有的Office功能，使它们符合沙箱要求，并仍然利用完整Office套件的能力。

这些安全改进适用于我们应用程序的最新版本。我们的自动更新工具本身受益于上述几乎所有改进。每个更新包都由微软签名，并且每次下载包时都会验证该签名。我们不断改进用户体验，以减少安装更新的工作量，并使其成为自动完成的无形操作。这鼓励我们的用户始终安装最安全的应用程序版本。

将所有这些变更结合在一起，使Mac版Office 2016成为我们迄今为止最安全的版本。我们在编译时启用更严格的编译器安全功能，构建和链接时预期ASLR在启动时将我们随机放置在内存中，审计不安全的API并将其从代码库中禁止，模糊输入以验证数据解析，禁止堆执行，选择加入macOS沙箱，在运行时使用地址消毒器寻找可能的安全缺陷，并使用户更可能拥有最新的安全更新。所有这些在可能恶意的代码面前设置了非常高的障碍，有助于保护您的应用程序、您的数据和您的Mac。

Erik Schwiebert，Mac版Office首席软件工程师