要約

  • GitHub の bypass_actors は ruleset をバイパスできる主体を示す設定であり、個別の行為の監査記録ではない。
  • rule suite は別の証拠面である。公開された例には主体、ref、前後の SHA、結果、評価結果、個々のルール評価が含まれる。
  • 重要な例外では、ポリシー版、能力、評価された遷移、別建ての承認、後続のリリースやデプロイの観測を混同せず保存する必要がある。

「その主体はルールをバイパスできる」という説明は、しばしば出来事の説明のように扱われる。しかしこれは能力についての文である。GitHub は ruleset 内でバイパスを許す主体を定められる。この経路は障害対応、運用継続、責任分担のために合理的な場合がある。けれども、ユーザー、チーム、アプリ、役割、鍵が bypass_actors に入っているだけでは、push、pull request、特定 ref の評価、実際のバイパス、承認のどれも立証されない。

設定には固有の意味がある。ruleset の記録は、対象、条件、適用状態、規則、バイパス主体を示しうる。GitHub には版の履歴もある。そのため、ある時点でどのポリシーが記録され、誰がいつ変更したかは追える。だが、特定の変更遷移で何が起きたかは別の問いである。版付けされた規則はトランザクションの受領証ではない。

API にあるモードは限界を分かりやすくする。GitHub は always、pull_request、exempt を区別する。exempt ではルールは実行されず、バイパス監査エントリも作られない。これは免除が不適切だという意味ではない。現在の許可リストから過去のすべての例外を推定してはいけないこと、また記録がないことから関連行為がなかったと断定してはいけないことを示している。

特定の遷移については、rule suite が別の限定された記録になる。GitHub はこれをルール評価の集合と呼び、ref、期間、主体、結果、評価状態で絞り込める。例には主体、リポジトリ、ref、前後 SHA、時刻、結果、評価結果、個別規則の評価が含まれる。result: bypass の suite は、プラットフォームがその特定の遷移をバイパスとして扱ったという範囲で有用である。それでも、必要な人の承認、例外の妥当性、マージ、リリース、実運用への配備までを一括して証明するものではない。

ルールの重なりも考慮しなければならない。GitHub は ruleset とブランチ保護規則が同時に機能し、該当する規則がすべて適用されると説明する。単一の ruleset だけを見れば、その ref に効いたポリシー全体を取り逃すことがある。一方 suite は複数の規則源の結果を表示できても、レビューや統治判断の完全な記録にはならない。どの版のポリシーがどの ref と SHA 遷移に適用され、プラットフォームが何を評価し、承認や運用結果はどの別記録が示すのかを分けて問う必要がある。

Daniel Kade が勧めるのは小さな例外受領記録である。リポジトリ識別子、正確な ref、前後 SHA、観測時刻、ruleset の出所と版または安全に保存したポリシースナップショット、主体とバイパスモード、suite の結果、評価結果、説明に必要な個別規則を結ぶ。承認が必要なら、その識別子、決定者、範囲、時刻を別に残す。後のマージ、タグ、リリース、デプロイも別の観測として扱う。秘密を公開せずとも、能力、実行、承認、結果の境界は保てる。

これは通常の状態も正確に表現する。許可を持つ主体が一度も使わないこと、別記録で正当に承認されたバイパスがあること、ポリシーだけが変わること、ref は変わってもリリースされないことは、いずれもあり得る。問題は例外の存在ではなく、一つの記録を別の記録の代わりにすることである。

情報源

  1. GitHub Docs — ruleset について
  2. GitHub Docs — rules の REST API
  3. GitHub Docs — rule suites の REST API