generic language vs contextual guidance

[ctcpip]

in docs/SCM-BestPractices/README.md, there is language that does not apply to all audiences

to elaborate on the contextual differences to which guidance will be different, in consideration are:

• OSS projects with a small number of maintainers with no GH org
• OSS projects with a small number of maintainers with a GH org
• OSS projects run by a larger community, perhaps with governance
• OSS projects run by companies, which can have varying levels of community engagement and contribution, policy, etc.
• ... and so on

examples of guidelines that would not apply in some cases:

• Organization Management Should Be Consolidated Under a Central Account.
• Organization Membership Should Be Limited to Employees.

the two options I see are:

• make the language/guidelines generic enough to apply broadly enough for different situations. this could manifest as caveats, removing certain guidelines, or providing multiple options that are suitable
• have different, tailored guidelines that are contextual where prudent

[ljharb]

Good catch! I reviewed the list and here's some of my feedback (cc @caabernathy):

GitHub Actions Should Be Restricted To Selected Repositories GitHub Actions Should Be Limited To Verified or Explicitly Trusted Actions

These don't work when maintainers on a repo - which may only have write access - want to add a legit workflow that isn't already in the approved list. Write access needs to be sufficient for adding new actions out of previously unknown repos, or else a project can't be effectively maintained in the general case.

Repository Should Be Updated At Least Quarterly Project Should Be Updated At Least Quarterly

Why? Many OSS project repos don't need updates for years.

Default Branch Should Require Code Review Default Branch Should Require Code Review By At Least Two Reviewers

These are a nonstarter when there's only one maintainer.

Default Branch Should Not Allow Force Pushes

This is perfectly safe when there's only one maintainer, and often when there's multiple as well. Only release tags - and arguably released commits - must be treated as immutable.

OSSF Scorecard Score Should Be Above 7

This is unachievable for single-maintainer projects (the scorecard team has been given this feedback about their metrics for well over a year already, though)

Default Branch Should Require Linear History

This is a style choice, and also, Github doesn't allow it to work unless you enable rebasemerge or squashmerge, which are (subjectively) undesirable for a number of reasons.

Default Branch Should Require All Commits To Be Signed

This effectively prevents all open source contributions, because the barrier to entry for signing commits is too high for random contributors.

Default Branch Should Limit Code Review to Code-Owners

Most projects aren't so large that they need codeowners at all.

Organization Membership Should Be Limited to Employees. Group Membership Should Be Limited to Employees.

In past organizations, I've found this requirement incredibly restricting and have advocated for its removal. Org membership needn't inherently confer any dangerous permissions, and since Github doesn't allow non-org-members to be on teams (i'm not familiar with gitlab), and team-based access control is FAR more secure than adding outside collaborators, I think this requirement actually meaningfully reduces security.

Organization Should Use Single-Sign-On

That's not an option for open source projects.

[david-a-wheeler]

As noted in Open Source is Bigger than You can Imagine, there are a huge number of OSS projects (including important projects) that have exactly one maintainer. There are a number of OSS projects that don't need to change often; in particular, if there's a small amount of code, often there really isn't anything that should be changed. The only time "is-even" might need to change is when the JavaScript specification adds a new primitive type, and that might never happen... it certainly would be years between such an event.

[torgo]

We looked at this in today's SCM call ... feels like this could be split apart between:

• items that could be PRs to some of the content written in the index files - such as the guidance for organizations.
• something to do with how we apply personas to each of the recommendations - maybe this could be an annotation of the list of best practices in some way?
• PRs to de-duplicate some items such as multiple 2fa-related items

We think we probably need a working session to work through this.

[SecurityCRob]

@torgo what's the state of this issue?