Protect source and CI

Require reviewed changes

Protect release branches, require focused review and passing checks, and make emergency bypass visible and temporary.

A protected branch turns the expected release path into an enforceable rule. Review is strongest when the change is small enough to understand.

Without protection, “we always review changes” is a habit, and habits fail under deadline pressure. On GitHub, a branch protection rule or ruleset on main makes the process mechanical: require pull requests, require current approvals, require status checks to pass, and block force pushes.

Two settings matter more than people expect. Dismiss stale approvals means a new push after approval needs a fresh review — otherwise an attacker can get a harmless diff approved and then push the real payload. Require branches to be up to date means the checks ran against the code that will actually merge.

You can verify what a branch actually enforces:

gh api repos/acme/api/branches/main/protection --jq '{reviews: .required_pull_request_reviews.required_approving_review_count, checks: .required_status_checks.contexts}'

If that returns a 404, the branch is not protected at all, whatever the team believes.

Protect the files that control the pipeline

A pull request changes application code and the workflow that tests it. The altered workflow reports success without running the security check, so a green badge alone does not represent independent review.

Give pipeline-defining files stricter owners with a CODEOWNERS file:

/.github/workflows/  @acme/release-admins
package.json         @acme/platform
package-lock.json    @acme/platform

With code owner review required, changes to workflows and dependency manifests need approval from those specific teams, not just any teammate.

Make bypass visible, not impossible

Emergency bypass can be necessary during an outage. The tradeoff is concentrated authority, so the bypass must be attributable, time-bounded, and reviewed afterward. An admin override that appears in the audit log and triggers a post-incident review is a control. A permanently disabled rule “because deploys were annoying” is a hole.

Create a test branch rule that requires one approval and one real status check. Save evidence that a failing unreviewed change cannot merge. Then exercise the documented bypass in a disposable repository and show where the event is logged and how normal protection is restored.

Lesson completed

Take this course offline

Get every free book, course edition, and software download.

Get the download library →