What is Branch Protection?
Before we dive into the weeds of this amazing suite of features, let’s get clear on what branch protection is. Branch protection is a range of controls within your source code management platform (e.g. GitHub, GitLab, Bitbucket, Azure DevOps) designed to control which actions can be executed against the git repositories. It allows repository administrators to enforce highly flexible, highly specific rules on git branches, such as requiring pull request reviews, status checks before merging, and more.
Why Branch Protection is Important?
The world of software development can be chaotic. You’ve got many developers – and now code GPTs – contributing in parallel to a project, all with their own changes.
Branch protection facilitates a structured workflow for developers, where code contributions are scrutinized and tested, ensuring that only code that meets the team's standards is merged. This is particularly important in "inner sourcing" models, where everyone has "write" access to the source code repositories, but branches that are deployed to higher environments are protected. This setup strikes a balance between fostering collaboration and innovation among developers and maintaining the necessary control and standards for secure code that affects production environments.
What is “Inner sourcing” and how does it work?
In an "inner sourcing" model, while all developers have the ability to contribute code, not all contributions are treated equally. For instance, branches destined for production deployment are shielded by branch protection rules. This means that although developers can freely contribute to the codebase, their changes must undergo a rigorous review and testing process before being deployed to more sensitive environments. Inner sourcing leverages the collective expertise and creativity of the entire team while ensuring that the deployed code is secure, reliable, and aligned with organizational standards.
Branch Protection Contribution to DevOps Governance
Branch protection plays a pivotal role in DevOps governance by enforcing a set of policies and practices that guide the development and deployment process. Key considerations include:
- Approval Requirements: Depending on the sensitivity of the area, branch protection rules can mandate one or more reviewers to approve pull requests before merging. This ensures that changes are examined by multiple sets of eyes, especially in critical areas of the codebase. It also proves that change management is in place for production code changes.
- Status Checks: To maintain code quality/security and prevent disruptions, certain status checks, such as successful builds or passed tests, must pass before merging. This automated gatekeeping ensures that only code that meets the predefined benchmarks can be integrated, such as ensuring the no new high severity vulnerabilities are introduced in the code changes.
- Conversation Resolution: The setting "Require conversation resolution before merging" ensures that all review comments and discussions are adequately addressed before code is merged. This holds developers to a higher standard of accountability and improves code quality and security.
Branch Protection Contribution to DevSecOps Governance
Branch protection is equally essential in DevSecOps, where security is integrated into the development process:
- Reviewer Rights: It's important to ensure that only approvals from individuals with the appropriate rights (e.g., CODEOWNERS) are considered valid, reducing excessive permissions and ensuring that changes are reviewed by subject matter experts. It is worth mentioning that any developer can review pull requests, but not every review or approval is counted towards the ability to merge the code, as the approver needs to be specifically defined in the CODEOWNERS file.
- Override Policies: In scenarios where high-priority fixes need to be deployed rapidly, certain users may need the ability to override branch protection policies. Monitoring such overrides is crucial for security teams to understand potential risks and ensure that security policies are not circumvented.
- Bypassing Policies: Controls should be in place to prevent or monitor when users bypass branch protection policies, such as force pushing or merging without additional reviews on a pull request.
Branch Protection Policies vs. Rulesets
Branch protection policies and rulesets both offer frameworks for implementing governance controls, but they cater to different needs:
- Branch Protection Policies are specific to individual branches within a repository, allowing for granular control over how code is reviewed, tested, and merged. They are ideal for projects requiring specific safeguards on critical branches.
- Rulesets, on the other hand, can be applied at a more macro level, such as across an entire organization or repository. They offer a broader, more standardized approach to governance that can be consistently applied.
The choice between branch protection policies and rulesets depends on the specific needs of the project or organization. While policies offer detailed control at the branch level, rulesets provide a uniform standard across all projects. Managing conflicts between the two requires a clear governance structure that prioritizes overarching rulesets for general standards while allowing individual branch policies for project-specific requirements.
Branch Protection Policies to Consider
Below is a list of branch protection policies, which can be configured per branch or org-wide, with a breakdown of value and risk impact:
| BRANCH PROTECTION RULE |
EXAMPLE USE CASE |
SECURITY VALUE |
| Restrict creations (Only allow users with bypass permission to create matching refs) |
Prevent creating new release branches by unauthorized personnel |
Low – unless automated CI/CD pipelines are kicked off based on naming convention, then Medium due to a potential software supply chain security risk. |
| Restrict updates (Only allow users with bypass permission to update matching refs) |
Prevent changes to a release tag on a package that is built and published |
Medium – unexpected update can potentially cause a software supply chain attack |
| Restrict deletions (Only allow users with bypass permissions to delete matching refs) |
Reduce the size of the repo |
Low |
| Require linear history (Prevent merge commits from being pushed to matching refs) |
Simpler code review process |
Low |
| Require signed commits (Commits pushed to matching refs must have verified signatures) |
Validate the author of the code, as the author can be easily spoofed. |
Medium – but effort is high. |
| Require a pull request before merging -> Require Approvals |
Require at least 1 approver on a PR before merging |
High – ensures a minimum change control in place |
| Require a pull request before merging -> Dismiss stale PR approvals when new commits are pushed |
Ensure that a PR that was approved doesn’t have new unapproved code changes. |
High – ensures a minimum change control in place and reduces the risk of an insider threat pushing malicious code after code was reviewed |
| Require a PR before merging -> Require review from Code Owners |
Ensure that only authorized PR reviewers' approval is counted towards the ability to merge code |
High – PRs cannot be merged until reviewed by the right personnel, in many cases – the subject matter experts. |
| Require a PR before merging -> Require approval of the most recent reviewable push |
Prohibit developers from self-approving PRs by requiring at least 1 PR reviewer |
High if the minimal approvers count is 1; Otherwise, medium. |
| Require a PR before merging -> Require conversation resolution before merging |
Address all PR comments before the code is merged for better security and quality |
Medium, as security gates can be enforced in a more effective way via Status Checks. |
| Require status checks to pass |
Require given status checks to pass, such as successful build. |
High, if the status checks are related to security gates. Low otherwise. |
| Block force pushes (Prevent users with push access from force pushing to refs) |
Solve merge conflicts in a more disruptive way, or change the refs to specific commit hashes |
High – force push can potentially override one branch with another without a PR. |
Detecting vs. Enforcing with Branch Protections
When rulesets are applied, the enforcement status can be configured with “evaluate”. It is good to enable the rulesets in this mode to ensure the expected results are applied before enforcing the policies.
The shift from “evaluate” to “active enforcement" can be gradual. For example, a subset of the repositories can be in evaluation stage for longer time while others can be converted to enforcement mode.
Conclusion
Branch protection is a cornerstone of modern secure software development practices, offering a balance between collaborative flexibility and stringent control. Whether through enforcing review processes, automating status checks, or integrating security considerations, branch protection mechanisms enhance both DevOps and DevSecOps governance. By carefully selecting and implementing the right policies and rulesets, organizations can protect their codebases while fostering an environment of innovation and security.
