Migrate Github Protected Branch/Tag Rules rules to Github Repository Rules rulesets

Open
#38 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
github
Domain
security

Research direction

Start with the migration goals and linked GitHub Repository Rules discussions, then review the repository checklist, including the completed strong-error-handler entry. Define which existing protected branch and tag rules must become rulesets and what disabling the older rules and API means; completion is a documented, agreed migration plan or applied repository configuration.

Written by the indexing model from the issue text.

Description

Github Repository Rules, which has reached general-availability, is an evolution of Github Protected Branch/Tag. This issue is to track:

  1. Converting existing Github Protected Branch/Tag rules to Github Repository Rules rulesets
  2. Disabling the older branch protection rules and api

Further discussions

With this new solution, we should also consider the new potentials for enforcing repository security.

Org-wide enforcement

Enforcing an org-wide Github Repository Rules ruleset is only available for Github Enterprise users. However, we can consider creating a Github Action workflow in https://github.com/loopbackio/cicd to periodically poll and enforce. This would be of similar concept to our potential adoption of Peribolos (https://github.com/loopbackio/cicd/issues/26).

Although the adoption of the OpenSSF Scorecard Action (https://github.com/loopbackio/security/issues/25) would allow us to detect non-compliance, it is not granular enough, does not have auditable self-remediation capabilities, and does not provide a single pane of glass.

Restricting bots' branches

TLDR: This is not fully possible.

Bots such as Renovate require push-rights to our Github repositories. However, this opens us up to third-party vendor risk where misused bot credentials can cause unwanted, destructive commit and tag modification to our repositories.

This is already partially-alleviated with the older Github Protected Branch/Tag feature, where we're able to mandate the creation of a pull request and restrict who can push new Git tags. However, we are not able to enforce this for the non-publishing (i.e. work-in-progress) branches which are created and deleted day-to-day.

Although Github Repository Rules allows layering and creation of bypass lists, it does not have an "apply to select bots/people only". This means that, even with a bypass list with non-bot members, we would still need to "bypass " the rules (i.e. "override" the rule) via the pull request page every time we want to merge. This is not ideal.

Repositories

Dominant language
TypeScript
Stars
4
Forks
1
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from loopbackio/security

All issues in loopbackio/security

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.