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.
Github Repository Rules, which has reached general-availability, is an evolution of Github Protected Branch/Tag. This issue is to track:
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