I'd start with Tier 1 (I've asked for that before in different language) and also Tier 2 and Tier 3. Tier 4 is overkill.
On Wed, Jul 30, 2025 at 11:02 AM Sandra Parsick <san...@parsick.dev> 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 > -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
