第 23 集：作者：Akash Mukherjee 在加利福尼亚州山景城（2021 年 7 月）
上一集
构建 Chrome 时，很多组件都会为环境做出贡献，而这些因素会影响工件的输出。 从操作系统开始，已安装的支持库、第三方依赖项、已安装的工具和运行时环境本身；这二者均采用各种安全状况级别构建。
过去，Google 使用二进制授权，这是一种内部运行时强制执行检查，旨在确保 Google 平台上部署的正式版软件和配置经过适当审核并且具有可追溯的来源，从而最大限度地降低内部风险。
Google 可确保任何人都无法在不被检测到的情况下入侵基于 LUCI 构建的工件的 build 和供应链，从而降低我们向用户交付的软件的风险。
从去年开始，对于每个 build，系统都会为每个 build 生成可验证的 build 清单，其中包含已签名的 JWT，详细说明了构建过程中的源代码、生成的二进制文件和工件的加密哈希，以及完整的构建参数。借助此构建清单，我们可以将工件追溯到源代码，从而使构建流程及其输出可验证。
此外，该清单还让我们能够验证构建的工件未被修改，因为任何更改都会导致签名失效。总的来说，这为工件在可信系统之间遍历提供了监管链。
Binary Authorization 以两步式系统的形式实现。系统会生成包含构建时间信息的provenance；在为软件签名或安装软件之前，强制执行政策。
def CreateProvenance(self, build_manifest: Mapping[str, Any]):
"""Builder generates and signs provenance given build manifest. Signed JWT is placed
alongside built artifact."""
对于 Chrome，在使用 Google 的签名基础架构为生成的软件工件签名之前，系统会强制执行此政策，以满足相应 build 的特定最低安全要求。
def VerifyProvenance(self, artifact_hash: str, provenance: str):
"""Provenance is verified using a policy engine service before signing an artifact."""
要求大致分为 4 个方面：
- 源代码控制：保护进入构建阶段的数据。
- Build：保护将源代码转换为二进制文件的进程。
- 出处：包含可验证的 build 清单的证明。
- 政策：用于确定给定工件是否符合给定上下文的规则。
在 Chrome 和基础架构的 CI 和 CD 流程中实施政策强制执行检查，这使我们能够验证代码和配置是否符合特定的最低安全标准。这是一项关键的控制措施，可用于限制可能恶意的内部人员或被盗用的内部帐号修改我们分发给用户的软件。