Confirmed users
1,351
edits
GitHub/Repository Security: Difference between revisions
move definition of "sensitive repo" to the terminology section
(Clarify scope of signing for now) |
(move definition of "sensitive repo" to the terminology section) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 5: | Line 5: | ||
The permissions model on GitHub, especially for older OAuth authenticated apps, is quite broad -- what you enable for one project applies to all projects you have access to. | The permissions model on GitHub, especially for older OAuth authenticated apps, is quite broad -- what you enable for one project applies to all projects you have access to. | ||
This can expose repositories with sensitive information to risks, without the repository admins being aware of risks. The following guidelines should be applied to all sensitive repositories hosted on GitHub | This can expose repositories with sensitive information to risks, without the repository admins being aware of risks. The following guidelines should be applied to all sensitive repositories (defined below) hosted on GitHub. | ||
The purpose of this checklist is to provide a base level of protection against compromise of credentials that may have the ability to modify repository resources (code, wikis, issues, etc.). Those credentials could belong either to an individual, or given to GitHub extensions. | The purpose of this checklist is to provide a base level of protection against compromise of credentials that may have the ability to modify repository resources (code, wikis, issues, etc.). Those credentials could belong either to an individual, or given to GitHub extensions. | ||
| Line 31: | Line 25: | ||
; Release: | ; Release: | ||
: Any distribution of the code, or artifacts generated from the code, for external use. "Release" includes deployments to staging or production hardware, "code drops" into another project, and similar milestones. | : Any distribution of the code, or artifacts generated from the code, for external use. "Release" includes deployments to staging or production hardware, "code drops" into another project, and similar milestones. | ||
; Sensitive Repository: | |||
: This term includes (but is not limited to): | |||
:* Repositories containing code that is directly or indirectly part of the Firefox product delivered by Mozilla. | |||
:* Repositories containing code that is run in production as part of services supporting the build, release, or ongoing operations of Firefox. | |||
:* Repositories containing PII or 3rd party IP which Mozilla has a contractual obligation to protect | |||
= Guidelines = | = Guidelines = | ||
| Line 57: | Line 56: | ||
- [ ] When creating a release, all commits which compose that release should first be audited. | - [ ] When creating a release, all commits which compose that release should first be audited. | ||
- [ ] Elevated permissions should be granted to teams, not individual accounts, whenever possible. (Only org members can be part of a team.) | - [ ] Elevated permissions should be granted to teams, not individual accounts, whenever possible. (Only org members can be part of a team.) | ||
- [ ] Enable [Automated Security Fixes][1] for the repository. If the vulnerability is not applicable to your repository, document that in the PR, then close ( | - [ ] Enable [Automated Security Fixes][1] for the repository. If the vulnerability identified by Dependabot is not applicable to your repository, document that in the Dependabot PR, then close the PR (don't merge the PR). | ||
[1]: https://help.github.com/en/articles/configuring-automated-security-fixes | [1]: https://help.github.com/en/articles/configuring-automated-security-fixes | ||