Add github hardening page #13
Conversation
src/github.md
Outdated
| @@ -1 +1,28 @@ | |||
| # GitHub hardening | |||
|
|
|||
| Since the Stacks ecosystem does the bulk of its development work in public repositories, it is crucial that those repositories be hardened against attack. Any weakness in their configuration exposes our developers and users to attack vectors, as we have seen in previous attacks against the ecosystem from nation-state sponsored attackers. The following policies MUST ALWAYS be implemented on EVERY repository. | |||
There was a problem hiding this comment.
Please add that having an Enterprise account allows setting this up at the org level (which applies it by default to all repos).
src/github.md
Outdated
|
|
||
| `git` does not, by default, do anything to verify that a commit comes from the user whose email address is tied to it. This address is simply metadata, and a compromised developer machine can alter this data at any point in the commit/push process; we saw exactly this in previous attacks. | ||
|
|
||
| To combat this, you MUST require signed commits on your repositories. You SHOULD require all users to enable `vigilant mode`, which adds an extra layer of obviousness when commits are unsigned. This will prevent one infected developer from impersonating others. |
There was a problem hiding this comment.
Please add link to vigilant mode.
Please also link to how to sign commits through SSH.
I know this is kinda weird because we are talking to admins, but also to users in this particular case).
src/github.md
Outdated
|
|
||
| First, you MUST disable force pushes against your main branch. This prevents an infected developer from altering the history of a branch, in order to hide a malicious commit by making it appear to have happened in the past. | ||
|
|
||
| Next, you MUST require all changes to your main branch to go through the pull request process. You SHOULD require two or more approvals for each PR. |
There was a problem hiding this comment.
Also in the PR dismiss it on new pushes.
|
|
||
| Finally, you MUST protect the main branch from deletion. | ||
|
|
||
| ## CI |
There was a problem hiding this comment.
I'd also add to use zizmor for vetting CI workflows and also NEVER using pull_request_target.
There was a problem hiding this comment.
Done. To be clear though, we do use pull_request_target on this repo currently.
src/github.md
Outdated
|
|
||
| Continuous integration is a powerful tool for preventing regressions in code, and allows us to make changes without unexpected side effects. However, CI MUST be hardened in specific ways to avoid causing other problems. | ||
|
|
||
| 1. You MUST NOT include secrets in CI! Instead use the github `secrets` APIs, which allow fine grained access control. This can for example limit access to specific jobs run by specific people. |
There was a problem hiding this comment.
Also use environments and require reviews (similarly to PRs) before deployments start.
…mode; require dismissing stale reviews
3 participants
No description provided.