How would you decide who may bypass GitHub branch protection, and keep it auditable?

## Why this is a judgment question Every bypass is a hole in a control you have told auditors, regulators and your own engineers is enforced. But a policy with no escape hatch fails badly at 3am, when the fix for a production outage is blocked by a required check whose runner is down. The design task is not "allow or forbid" but "make the exception rare, attributable, and reviewed". ## Start from deny Both models default to a closed position and both make it easy to open accidentally. In classic branch protection the toggle is a single checkbox covering repository administrators; leaving it unticked means every admin is silently exempt from everything on that branch, which is the most common accidental hole in the wild. Rulesets replace that with an explicit `bypass_actors` list, which is better precisely because it is an enumeration: an empty list is unambiguous, and every entry is a decision someone made. ## Grant to roles and identities, not people Three principles cover most cases: - **Roles and teams over individuals.** Role and team entries stay correct when people join and leave; a list of five usernames rots into a list of two leavers and a contractor. - **Apps over humans for automation.** A release bot, a dependency updater, or a migration tool should hold its own GitHub App installation with a scoped bypass, rather than someone lending it a personal admin account. The app identity is visible in the audit trail as itself. - **Scope narrowly.** Rulesets let an entry bypass **always** or **for pull requests only**. The latter is almost always the right choice for humans: the change still goes through a pull request, is still visible and reviewable, and only the specific rule (say, a stuck required check) is skipped. Reserve always-bypass for automation that genuinely must push. ## Separate emergency from routine If people bypass weekly, the policy is wrong, not the people. Rising bypass counts are a signal to fix the underlying friction: a flaky required check, an approval requirement that a two-person team cannot satisfy, a rule inherited from a template that never fitted the repository. Design the break-glass path so that using it is *possible but conspicuous*: a named on-call role holds it, invoking it is announced in the incident channel, and the follow-up is a ticket that either removes the need or accepts it explicitly. A useful alternative to standing bypass is **temporarily changing the policy** rather than skipping it: an org owner sets the ruleset to disabled, the fix lands, the ruleset goes back to active. That is itself an audited configuration change with a clear before and after, and it leaves no permanent exemption behind. It is slower, which is a feature. ## Make it observable Three surfaces matter: - **Rule insights** shows, per ruleset, which pushes and merges were evaluated, which rules fired, and which were bypassed and by whom. - **The organization audit log** records the configuration changes — who added a bypass actor, who disabled a ruleset, who edited branch protection — which is the more dangerous class of event, because a quietly added bypass produces no further alerts. - **Rulesets are readable by anyone with repository read access**, unlike classic protection, so exemptions are not a secret held by admins. That transparency is itself a control. Wire the audit-log stream into wherever your security signals land and alert on *policy edits*, not just on bypass usage. Review the standing bypass list on a fixed cadence — quarterly is typical — and delete anything whose owner cannot restate why it exists. ## Roll changes out, don't drop them When tightening bypass across many repositories, use the enforcement status: publish the stricter ruleset in **evaluate** mode where the plan offers it, look at rule insights for what would have been blocked and who would have needed an exemption, fix those cases, then switch to active. This turns an organization-wide policy change from an outage into a measurement. ## Organizational placement Put non-negotiable rules in an **organization ruleset** so a repository admin cannot quietly relax them — repository-level policy can add strictness but never subtract it, and organization rulesets are edited only by org owners. Leave repository-level rulesets for the extra strictness each team wants. That split makes the bypass conversation tractable: there is one place where exemptions to the baseline live, and one owner for it. ## Interview framing Answer as an owner: default deny, grant to roles and app identities, scope to pull requests, keep a deliberately conspicuous break-glass path, alert on policy edits as well as bypass usage, review the list on a cadence, and stage changes through evaluate mode. Add the diagnostic instinct — a rising bypass rate means the rule is wrong — and you have shown the judgment the question is testing.