CI/CD Governance

2 practices · CI/CD governance guidance + release-engineering best practices

Who can merge and who can deploy. Short list, high leverage — these two items are what stop an unreviewed change reaching production.

Ticking these off for a specific project? The Project Security Checklist tracks all nine categories in one place. For why these patterns keep recurring, see Security Best Practices.

1. Branch Protection With Required Code Review

Description

No one — including admins — pushes directly to the production branch. Every change goes through a pull request with at least one required approval and passing CI, so a mistake or a malicious change can't reach production without a second set of eyes.

Example 
GitHub branch protection on main:
require 1 approving review, require status checks,
include administrators, no force-push

2. Gated Production Deployments With a Named Approval Process

Description

Write down, and enforce in tooling, exactly who can deploy to production and what has to be true first — passing CI, a merged PR, a specific role. "Whoever has the credentials" is not an approval process.

Example 
GitHub Actions environment protection rule:
"production" requires 1 reviewer from #deploy-approvers
before the deploy job runs

Last updated: September 2026 · Source: Offspring — Security Best Practices.pptx (Part 4) + Security Best Practices Checklist.xlsx