skip to content

How would you enable GitHub push protection org-wide without stalling every team?

level: principalimportance: should knowfreq 30%

answer

  1. Watch before you block
  2. The backlog is triaged, not cleared
  3. Fake-looking fixtures cause the first outage
  4. Exclusions silence alerts, not the block
  5. Bypass reasons are your health metric

basics

~20 s

Enable alerting everywhere first through an organisation security configuration, triage the historical backlog by validity, then turn push protection on in waves. Fix fixture and sample false positives before blocking, and use delegated bypass only where the risk justifies the latency.

solid answer

~50 s

Sequence it. **Alerting first:** apply an organisation-level security configuration enabling secret scanning across all repositories, and set it as the default for new ones, so coverage does not decay. That gives you the historical backlog — triage it by **validity** and blast radius rather than trying to clear it, because a live production key matters and a dead fixture does not. **Then block, in waves:** enable push protection on a pilot group, watch what gets blocked, and fix the systemic false positives — obviously-fake sample values in documentation and tests, and `.github/secret_scanning.yml` `paths-ignore` for genuine fixture directories, remembering that path exclusions govern **alerting** and do not exempt a push from being blocked. **Govern the escape hatch:** leave bypass self-service in most places and enable **delegated bypass** where a leak would be most costly. Review bypass reasons as a programme metric. And make sure rotation is actually possible before you make blocking mandatory — a control that people cannot comply with gets turned off.

code

yaml · 6 lines
yaml
# .github/secret_scanning.yml
# Suppresses ALERTS for these paths. Push protection still blocks a push.
paths-ignore:
  - "tests/fixtures/**"
  - "docs/samples/*.md"
  - "**/testdata/seed-*.json"

go deeper

for a junior

Know that these settings can be applied across a whole GitHub organisation at once rather than repository by repository, and that turning on blocking has an effect on everyone's day.

for a middle

Be able to explain the difference between enabling alerting and enabling blocking, and name the artefacts involved: an organisation security configuration and the repository secret scanning configuration file.

for a senior

Show the staged plan and the false-positive work that has to happen before blocking, plus realistic triage of a historical backlog by validity rather than by count.

for a principal

Own the whole programme: sequencing, the metric set, where bypass is delegated versus self-service, and the precondition that teams must actually be able to rotate credentials before you make blocking mandatory.

## The failure mode you are designing against The naive rollout is: enable push protection everywhere on Monday. By Wednesday several teams are blocked mid-release by test fixtures that look like keys, someone with admin rights turns the feature off for their repository, and the security team has spent its credibility. The programme design problem is not technical enablement, it is the order in which you introduce a blocking control into an organisation that has never had one. ## Phase one: see before you block Enable secret scanning **alerting** everywhere first, via an organisation security configuration applied to all repositories and set as the default for newly created ones. Two things come out of this phase: - **A backlog.** Full-history scanning will surface credentials committed years ago. Do not attempt to zero it. Prioritise by validity status (is the credential still active?) and by what the credential reaches. Live keys to production systems are an incident queue; dead keys in an archived repository are a cleanup task that may never justify itself. - **A map of your false positives.** You learn which teams keep realistic-looking sample values in documentation, tests and seed data. That is exactly the population that will be blocked in phase two, and you can fix it before it becomes a work stoppage. ## Phase two: block, in waves Enable push protection on a pilot: teams that are willing, plus your highest-risk repositories. Watch what gets blocked and classify it. Two remedies, in order of preference: 1. **Change the data.** Replace realistic sample credentials with values that are obviously fake and structurally invalid. This removes the block permanently and improves the codebase. 2. **Exclude the path from alerting.** A `.github/secret_scanning.yml` file with a `paths-ignore:` list suppresses alerts for the listed locations. Use it sparingly — it is a permanent blind spot in a directory, and directories accumulate new files. Crucially, exclusions shape **alerting**; do not present them to teams as a way to make push protection stop blocking a live credential. Then widen the waves. Keep the fast path visible: the most common block is an honest mistake by someone who now needs to rewrite one local commit, and whether they do that or reach for bypass depends entirely on whether the recipe is one click away in your internal docs. ## Phase three: govern the escape hatch Bypass exists so the control does not become a work stopper, and removing it everywhere reliably backfires. Instead: - **Instrument it.** Bypass reasons are a programme metric. Mostly "used in tests" means you have a fixture problem to fix centrally. Mostly "I'll fix it later" means people are pushing real credentials under deadline pressure and your rotation story is bad. - **Delegate selectively.** Turn on delegated bypass — where an unblock becomes a request approved by a designated reviewer group — on the repositories where a leak is most expensive. Accept that it costs latency and needs someone reachable. Applying it universally is how you end up with a queue nobody staffs and pressure to disable the feature. ## The precondition nobody mentions Blocking is only reasonable if compliance is possible. If a team's only way to run their service is a long-lived static credential they cannot rotate without a coordinated outage, then push protection is telling them to stop working. Pair the rollout with the capability side: short-lived credentials where the platform supports them, a rotation runbook that does not require a change-advisory board, and a clearly-owned place for credentials to live instead of the repository. Otherwise your control is a tax on honesty — people will keep the credentials, they will just keep them somewhere you cannot see. ## What to measure - **Coverage** — repositories with scanning and push protection enabled, including new ones. - **Blocked-push count** — every one is a leak that did not happen. This is the number that justifies the programme. - **Bypass rate and reason mix** — the health signal; a rising "fix it later" share is a warning. - **Time to revoke** for alerts on active credentials — the exposure metric that actually matters. Not: total open alerts. It rewards dismissal and penalises coverage. ## How to pitch it To leadership: this control converts an incident class into a rejected push, and the evidence is the blocked-push count. To engineers: it is not another dashboard, it fires exactly once at the moment when the fix is still one local commit away. Both framings are true, and both are what make the rollout survive its first bad week.

  • Why enable alerting across the organisation before switching on push protection?
    Because alerting is non-blocking and shows you exactly what push protection will stop: the historical backlog and, more importantly, the realistic-looking fixtures and documentation samples that will block honest pushes. Fixing those first turns the blocking phase from a work stoppage into a non-event.
  • Does a .github/secret_scanning.yml paths-ignore entry stop push protection blocking that path?
    No. Path exclusions shape which matches raise alerts; they are not an exemption from the push-time block. Presenting them to teams as a way around a block sets a false expectation. If a directory legitimately contains credential-shaped test data, change the data to be obviously invalid instead.
  • When is delegated bypass worth its latency?
    On repositories where a leaked credential would be most expensive — anything touching production, customer data or signing material. Everywhere else the review queue is unlikely to be staffed fast enough, and an unstaffed queue produces pressure to disable push protection entirely, which is a strictly worse outcome.
  • What single number best justifies the programme to leadership?
    Blocked pushes: each one is a credential leak that did not happen and an incident nobody had to run. Pair it with time-to-revoke for alerts on active credentials, which shows the response side is real. Open alert count is a poor choice because it improves when people dismiss findings.

saying these in an interview costs you the question

  • Turns push protection on everywhere in one step
  • Tries to clear the entire historical alert backlog first
  • Presents path exclusions as a way around a blocked push
  • Enables delegated bypass org-wide with no staffed reviewers
  • Mandates blocking where credentials cannot actually be rotated

context

resolving links…