Hi Sandra,
Thanks for bringing this up! It sounds very interesting, I haven't heard
much about this before but I could see there are benefits in enabling
some of these protections.
I'm curious, since we have bidirectional sync between GitHub and the
Apache Gitbox. How effective would these measures be? Could one (a
malevolent actor) perform a force-push against a branch on the Gitbox
which would then nevertheless end up on GitHub as well? Or delete a
branch? Or... (you get the idea).
Thanks,
Maarten
On 30/07/2025 13:02, Sandra Parsick wrote:
Hi,
I have taken a more in-depth look at the branch protection checks of the
OpenSSF scorecard best-practices, and I'd like to discuss two topics:
1. Do we want to enable GH rules to pass some of them?
2. How do we want to enable the GH rules?
In their documentation [0] , following checks are documented, when the
score card checks are running without admin permissions:
This check determines whether a project's default and release branches
are protected with GitHub's branch protection or repository rules
settings. [....] Each tier must be fully satisfied to achieve points
at the next tier.
Tier 1 Requirements (3/10 points):
- Prevent force push
- Prevent branch deletion
Tier 2 Requirements (6/10 points):
- Require at least 1 reviewer for approval before merging
Tier 3 Requirements (8/10 points):
- Require branch to pass at least 1 status check before merging
Tier 4 Requirements (9/10 points):
- Require at least 2 reviewers for approval before merging
- Require review from code owners
Tier 5 Requirements (10/10 points):
*Only affected when scorecard check runs with admin priviledged*
Of course, the main critism can be "why to invest time in implementing
branch protection rules? Only for earning points to get a nice 'trophy'?"
From the user perspective, having an OpenSSF badge with a good score on
the README can help the user to decide if it is valuable to take a
deeper look at the project. In our case, it would also show that the
Maven project cares about supply chain security.
From the maintainer perspective, we should look at every check and
decide check by check if they really help us in our daily work and how
high the effort is to implement passing the check.
Here is a first review of the best practices proposed by OpenSSF Scorecard:
- Prevent force push
This check can be satisfied with the GH branch rule 'Block force
pushes'. This rule prevents that someone or an automatismn can overwrite
the repository history accidentally (or consciously)
- Prevent branch deletion
This check can be satisfied with the GH branch rule 'Restrict
deletions'. This rule prevents that someone or an automatismn can delete
the master branch accidentally (or consciously)
- Require at least 1/2 reviewer for approval before merging.
This check can be satisfied with the GH branch rule 'Require a pull
request before merging' in combination with the setting 'Required
approvals = 1/2'. This rule in combination with that setting enforces
that at least one or two reviewer on every pull request. It can help to
reduce human failure like "This is only a small change, I don't need a
code review"
- Require branch to pass at least 1 status check before merging
This check can be satisfied with the GH branch rule 'Require status
checks to pass'. This rule enforces that merging a pull request is only
allowed when at least one status check is passed. It can help to reduce
human failure like "This is only a small change. It will not break
anything. Therefore, I don't want to wait until the check is done."
- Require review from code owners
This check can be satisfied with the introduction of a CODEOWNERS file
in every repository.
According to an initial check [1], currently no branch protection checks
are passed. But we have at least a rule that prevents force push on the
master branch.
From my perspective, passing the following checks can help us to avoid
typical human failures that are done mostly accidentally:
- Prevent force push
- Prevent branch deletion
- Require at least 1 reviewer for approval before merging.
- Require branch to pass at least 1 status check before merging
For passing the check 'Prevent force push' and 'Prevent branch
deletion', we need a refactoring of the current implementation using GH
repository rules [2], [3]. This refactoring would help to make it
visible from outside.
Passing the check 'Require review from code owners', a CODEOWNERS file
is needed in every repository. Maintaining such a file in every
repository that related to Maven could be painful. It belongs to Tier 4
and to pass Tier 4 all previous tiers have to be satisfied. Therefore,
IMHO, we should concentrate on the other ones.
Passing the check 'Require at least 1 reviewer for approval before
merging', the GH rule 'Require a pull request before merging' is needed
and that will be have an impact on the release process (m-release-plugin
is pushing changes directly to master branch). We can avoid this impact
if we maintain a bypass list so this rule can be worked around in
specific cases, or we can use this situation and rethink the release
process.
IMHO, we can decide rule by rule if one is helpful for us or not. I
don't think we need to decide like 'implement all rules or nothing.' It
also helps only to implement a few of them.
If we conclude that it is a good idea to implement such kind of rules.
The next question is how to enable the GH rules.
Thanks to Piotr, who mentions [4] the possibility of GH repository rules
[5], that can be implemented by calling a REST API. He also drew my
attention to the fact that ASF infrastructure already has support for
branch protection in .asf.yaml [6], [7] (but it seems we are not using
it in the Maven project). One idea could be to refactor this script
using repository rules (of course, we should also discuss it with ASF
infra). In case of we have reason not using ASF infra script, we can
implement such script by ourselves for the Maven source repositories
(similar to the shared GH action). Or maybe some one has another idea.
Best regards,
Sandra
[0] https://github.com/ossf/scorecard/blob/main/docs/checks.md#branch-
protection (opened on 2025-07-29)
[1] https://scorecard.dev/viewer/?uri=github.com%2Fapache%2Fmaven-
dependency-plugin (OpenSSF score card for m-dependency-plugin)
[2] https://docs.github.com/en/repositories/configuring-branches-and-
merges-in-your-repository/managing-rulesets/about-rulesets
[3] https://github.blog/news-insights/product-news/github-repository-
rules-are-now-generally-available/
[4] https://github.com/support-and-care/maven-support-and-care/issues/107
[5] https://docs.github.com/en/rest/repos/rules?apiVersion=2022-11-28
[6] https://github.com/apache/infrastructure-asfyaml/blob/main/.asf.yaml
[7] https://github.com/apache/infrastructure-asfyaml/blob/main/asfyaml/
feature/github/branch_protection.py
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
