摘要

  • GitHub 将 bypass_actors 定义为可以绕过仓库 ruleset 的主体；这是能力配置，不是一次具体操作的审计记录。
  • rule suite 是另一类证据：GitHub 的示例把一次评估同主体、ref、前后 SHA、结果、评估结果和单条规则评估联系起来。
  • 可核查的例外记录应分开保存策略版本、绕过能力、被评估的变更、独立批准和后续交付观察，不能让其中一项替代其他项。

“某人可以绕过规则”常被说成一个已经完成的故事。它实际上只说明能力。GitHub 允许仓库在 ruleset 中指定可绕过规则的主体。这种安排可以是为了应急、维护连续性或明确管理职责，因而本身并不反常。可是，一个用户、团队、应用、角色或密钥出现在 bypass_actors 中，并不证明它曾推送变更、发起拉取请求、作用于某条 ref、触发评估，或得到过批准。

配置记录并非没有价值。ruleset 的记录可以说明来源、目标、条件、执行状态、规则和绕过主体；GitHub 还提供版本历史。它们能够回答“当时登记的政策是什么、谁在何时修改过它”。它们不能回答“某一次代码转变发生了什么”。有版本的政策不是一次转变的收据。

绕过模式尤其清楚地划出边界。GitHub 的规则 API 区分 always、pull_request 与 exempt。对于 exempt，规则不会运行，也不会生成绕过审计条目。这不使豁免本身可疑，也不表示记录缺失就是错误；它只限制了可以做出的推论。当前的可绕过主体名单不能倒推出历史上所有实际绕过；缺少一条绕过记录也不能稳妥地证明没有相关行动。

若要理解一次具体转变，rule suite 才是另一块必要证据。GitHub 将其描述为规则评估的集合，可以按 ref、时间、主体、结果和评估状态过滤。其示例带有主体、仓库、ref、变更前后 SHA、时间、结果、评估结果以及逐条规则评估。一条 result: bypass 的 suite 可以支持一个有限判断：平台把这一次特定转变判作绕过。它并不自行证明所需的人类批准已经取得、例外理由已经认可、变更已经合并，或任何内容已经到达生产环境。

规则叠加使简单说法更危险。GitHub 说明 ruleset 与分支保护规则可以同时保护分支，所有适用规则都会执行。因此，孤立查看一个 ruleset 可能漏掉某条 ref 的部分政策；反过来，rule suite 可以展示多个规则来源的结果，却仍不是完整的评审或授权卷宗。严谨的问题应当是：哪一版政策对这条 ref 和这次 SHA 转变适用，平台实际评估了什么，另一个什么记录才足以证明现在要声称的批准或交付结果？

Daniel Kade 建议为重要例外保留一张受限的联结记录：仓库标识、确切 ref、前后 SHA、观测时间、ruleset 的来源与版本或安全保存的策略快照、绕过主体与模式、suite 结果、评估结果，以及解释平台结果所需的逐条规则。若还需要批准，应保存其独立编号、授权者、范围和时间；若后来合并、打 tag、发布或部署，也应各自留下独立观察。敏感细节可以受保护，但配置、执行、授权和后果不能被压缩成一个字段。

这种做法同样能如实记录平常情况。主体可能获准绕过却从未使用；某次绕过可能在另一份批准记录中得到妥当授权；政策可能变化而受保护 ref 没有变化；ref 可以变化却从未发布。它们都不等于事故。真正的风险是让一个记录承担它从未记录过的证明责任。

来源

  1. GitHub Docs — 关于 ruleset
  2. GitHub Docs — 规则 REST API
  3. GitHub Docs — rule suite REST API