第 23 集：作者：Akash Mukherjee in Mountain View, CA（2021 年 7 月）
上一集
在我们构建 Chrome 时，有许多因素会对环境产生影响，而这会影响工件的输出。 从操作系统、已安装的支持库、第三方依赖项和 安装的工具和运行时环境本身； 每种产品都有不同的安全性等级
过去，Google 使用二进制授权， 可最大限度降低内部风险的内部运行时强制执行检查 确保在 Google 部署的生产软件和配置 已经过适当审核，并且具有可追溯的出处。
确保没有人能破坏 build 以及基于 LUCI 构建的工件的供应链，而不被检测到； Google 可降低向用户交付的软件的风险。
从去年开始，系统会为每个 build 生成一个可验证 build 清单 - 签名的 JWT 完整描述了纳入构建的源代码 生成的二进制文件和工件的加密哈希以及完整构建参数。 这个 build 清单使我们能够将工件追溯到源代码， 从而使构建流程及其输出可验证。
此外，该清单还让我们能够验证构建的工件是否未被修改 因为任何更改都会使签名失效。 总的来说， 这为我们在可信系统之间遍历的工件提供了监管链。
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 清单的证明。
- 政策：用于确定给定工件是否符合给定上下文的规则。
在 Chrome 和基础架构的 CI 和 CD 流程中实施政策执行检查 我们能够验证代码 和配置是否符合特定的最低安全标准。 这是一项关键的控制措施， 或被盗用的内部人员账号 修改我们分发给用户的软件。