Skip to content

security-repository.md

Latest commit

 

History

History
58 lines (40 loc) · 5.2 KB

security-repository.md

File metadata and controls

58 lines (40 loc) · 5.2 KB

Securing repositories

This guide lays out security best practice for Github repositories. This set of practices is a minimum (nothing stops you from doing more), and they should be implemented alongside other relevant ones that contribute to security as a whole. These are discussed in more detail as part of the Quality Checks.

Prerequisites

Publishing Code within the Quality Checks page lists a minimum set of practices that should be in place before code is published. This implies that:

  • Repositories can only be secure once the listed practices meet the relevant amber/green thresholds (which should also be reflected in a Quality Dashboard).
  • The guidelines in this page are a necessary, but not a sufficient, condition for code overall being secure.

Access controls

Organisation-level settings

  • All users must have MFA enabled.
  • Baseline visibility for private repositories must be No Permission.
  • Ability to change repository view from private to public must be reserved to admins only.

Repository-specific settings

  • In line with the Service Manual, new repositories should be public by default, unless there is good reason not to - this avoids costly rework to secure private information further down the line.
  • Private repositories must disable forking.
  • There must be no outside collaborators in private repositories.
  • Enable abuse reporting by accepting content reports

Teams setup

Because of baseline visibility configurations, you must setup Github teams in order to provide team members access to repos. The minimum recommended setup is as follows:

  • Create one team with the name of your programme (e.g. Engineering Quality Framework). Add all required members to this team.
  • Create another team, for admins only (e.g. Engineering Quality Framework Admins). Add admins only to this team. Set the visibility of the team to Secret.
  • Create another team, for code owners (e.g. Engineering Quality Framework Code Owners). Set the parent of this team to be your programme team. Add relevant members to this team, and reference in the CODEOWNERS file (example here).
  • For each repo in your programme (e.g. software-engineering-quality-framework), under the Manage Access option in Settings, set the general team to have Write access and the admins team to have Admin access.

Depending on your use case, you may want to create additional teams (e.g. a read-only access team, or different teams granting access to different projects). This is welcomed by the framework, as long as the teams provide clarity on the role they encompass, remain consistent and are applied consistently to your repos.

Code security

  • Enable, at a minimum, Dependabot alerts for vulnerabilities and respond to them appropriately.
  • Disable ability to push to the default branch for everyone, admins included (applies-to-admin option).
  • Refer to Quality Checks for further code security practices.

Branch protection

  • Require pull request code reviews, by at least one code owner, to merge a branch.
  • Require signed commits, and, accordingly, check that commits are verified before merging. Git treats authentication and identity separately - any authenticated user can impersonate another developer when committing code. This means that even if a junior account is compromised it could have significant consequences, for example impersonating the lead developer in the hope of an easy merge. Only by requiring signing can identity truly be verified. Setup Guides for macOS, Windows, GitHub Actions, and AWS CodePipeline.
  • Invalidate existing reviews when new commits are pushed (fresh-commits-invalidate-existing-reviews option).
  • Require adequate automated status checks prior to merging. This should always include checking that branches are up to date.