Create a GitHub security best practices guide

[noamd-legit]

Proposal:

Creating a single document that compiles GitHub security best practices in a clear and consistent format.
The document will help security teams, DevOps engineers, and developers implement security best practices in the GitHub platform.
Additionally, such a document could assist in the development of software that automatically validates these configurations.

Rationale:

1. The GitHub platform contains many security-related settings that, if misconfigured, could impose serious security risks.
2. GitHub adds new features consistently, making it hard for security teams to keep updated with the latest security best practices and constantly understand the risk their configuration exposes.

Some Examples:

1. Code review is not enforced
2. Webhooks are configured insecurely
3. Stored secret is accessible to multiple users
4. MFA is not used by default
5. ...

Other examples can be found here: link

Who we are

We are Legit Security, a cybersecurity company that aims to secure SDLC and prevent software supply chain attacks. We have in-depth knowledge in the field of SDLC misconfigurations, and we'd love to help create this document.

[torgo]

I support the idea – AND I would like to make sure that the output of this work remains vendor neutral as per OpenSSF values. For example, we had this discussion when it came to the concise guide's wording about dependabot see point 7.

[noamd-legit]

@torgo I agree many concepts and ideas are similar between the source code management platforms. How would you handle the many SCM-specific features and configurations in such a document?

[torgo]

We discussed an approach in the call this week which I would characterize as "genericize where possible." So for example if turning on MFA is a best practice then we say that and provide information/links to how to do this on the most commonly used services. The group also resolved to work on this as a work item.

[laurentsimon]

I'm interested in helping out.

[balteravishay]

I am interested in helping out

[roberthstrand]

I'd like to help

[david-a-wheeler]

I recommend renaming to "Forge Best Practices Guide" or similar. SCM is bigger than GitHub/GitLab/etc. The conventional name for these kinds of systems are "forges" (descended from "SourceForge" which trailblazed the space), let's use that.

[torgo]

"SCM Platform Best Practices" maybe? TBH I am not sure I've heard "Forge" used that much in the wild...

[roberthstrand]

"Distributed SCM Configuration Best Practices" ? TBH I am not sure I've heard "Forge" used that much in the wild.

I was about to comment on that as well. I get the historical reasoning behind calling these types of systems "forges", but as far as I know it is not an industry term that is much in use all round. I think generalizing to SCM is the best way forward.

[derekmurawsky]

Some thoughts on this topic from a developer enablement and DevOps perspective.

RE: Best Practices Naming

SCM or VCS are the terms I hear most often used with tools like GitHub. A couple of thoughts, though...

RE: Generic vs tool-specific guidance

Can we adopt a pyramid approach where we set up the high-level and generic guiding principals up front, and then release best practices guidance that map to those for specific platforms like GitHub? It seems like this would be the best of both worlds and would encourage us to "eat our own dogfood" on the mapping to make sure it actually works. It would provide a relatively easy framework to add to over time.

RE: Usability and Practicality

Looking through a lot of the existing recommendations out there, and, specifically the ones linked in the OP, I do think we have to be mindful on how these recommendations will affect developer workflows. A specific example is
Workflows Are Allowed To Approve Pull Requests as a HIGH risk. To me, that is the dream goal! We should have our systems implement scans, check tests and coverage, and ensure there is a high quality deliverable without the need to a human to be involved. Automation is the way, imho.
Another example would be GitHub Actions Runs Are Not Limited To Verified Actions. This means you couldn't brew your own internally as it wouldn't be verified. There is a statement in there that says "or explicitly trusted actions" so maybe the title just needs work.
Without getting mired in specific examples, though, the general point is: we should be aware of the second and third order implications of both the general and specific guidance that is put together here. :)

[david-a-wheeler]

The term "forge" has a long history in industry, and even a Wikipedia page going back to 2008: Forge(software).

A problem with term "software configuration management" is that I don't think we intend to include the full meaning implied by software configuration management. In particular, in many circles "configuration" is generally understood to cover changes typically made by a system administrator.

[derekmurawsky]

The term "forge" has a long history in industry, and even a Wikipedia page going back to 2008: Forge(software).

A problem with term "software configuration management" is that I don't think we intend to include the full meaning implied by software configuration management. In particular, in many circles "configuration" is generally understood to cover changes typically made by a system administrator.

I always thought SCM was Source Code Management / Manager. I suppose it is an overloaded term, but I have never heard the term software forge in common parlance.

https://stackoverflow.com/questions/2575922/what-does-scm-stand-for
https://en.wikipedia.org/wiki/Git
https://aws.amazon.com/devops/source-control/
https://www.techopedia.com/definition/3879/source-code-manager-scm

[david-a-wheeler]

Just to be clear, I think "SCM" Is much better than making it specific to a particular forge, because I expect a lot of overlap.

[david-a-wheeler]

If we spell out "Source Code Management", it's much clearer. When I hear "SCM" I presume "Software Configuration Management", which as I said, is broader than intended.

[roberthstrand]

If we spell out "Source Code Management", it's much clearer. When I hear "SCM" I presume "Software Configuration Management", which as I said, is broader than intended.

This is probably one of those times when it depends on who is listening, but I have never associated SCM with anything other than "Source Code Management". But what if we are explicit about using the full name in all titles, and then use the shorter SCM after making it clear what we are referring to?

[david-a-wheeler]

@roberthstrand : Once you clearly define an abbreviation, it's fine to use the abbreviation. It would be prudent to re-introduce the term in various sections if we expect people to take a hyperlink into a specific section (and I do expect that). That's not limited to "SCM", I would do that with any abbreviation that might not be universal.

Different communities obviously define "SCM" differently. SCM means "Software Configuration Management" in many circles, my goal is to just help make it clear what it means in this document.

[torgo]

Since we've published the SCM guide we think this is closed. Of course work will continue on the SCM guide - and we encourage people to open new issues or raise PRs related to that document. ✨