From d65d25fae1cb81bf80ff77aafd0a1b0f8304de03 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Thu, 10 Aug 2023 11:36:20 +0100 Subject: [PATCH 01/31] Repo config - note on default branch name --- practices/securing-repositories.md | 1 + 1 file changed, 1 insertion(+) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 654d9e0b..5dc704f3 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -32,6 +32,7 @@ This guide lays out security best practice for Github repositories. This set of - Private repositories must disable forking. - There must be no outside collaborators in private repositories. - Enable abuse reporting by [accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) +- Default branch should be called "main", not "master" - please see [](../inclusive-language.md) for guidance on how to rename the default branch ### Teams setup From c107217c058be40685a81e41057c39eba4ab84ae Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:41:09 +0100 Subject: [PATCH 02/31] Update securing-repositories.md --- practices/securing-repositories.md | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 5dc704f3..2e012984 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -9,20 +9,15 @@ - [Code security](#code-security) - [Branch protection](#branch-protection) -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](security.md) as a whole. These are discussed in more detail as part of the [Quality Checks](../quality-checks.md). +In line with [NCSC guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) it is important to secure your code repository. -## Prerequisites - -[Publishing Code](../quality-checks.md#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](../insights/metrics.md)). -- The guidelines in this page are a necessary, but not a sufficient, condition for code overall being secure. +This guide describes our minimum set of requirements to secure & configure our Github repositories. This minimum set should be implemented alongside other relevant ones that contribute to [security](security.md) as a whole. These are discussed in more detail as part of the [Quality Checks](../quality-checks.md). ## Access controls ### Organisation-level settings -- All users must have MFA enabled. +- MFA must be enabled and enforced for all users. - Baseline visibility for private repositories must be `No Permission`. - Ability to change repository view from private to public must be reserved to admins only. @@ -30,9 +25,9 @@ This guide lays out security best practice for Github repositories. This set of - In line with the [Service Manual](https://service-manual.nhs.uk/service-standard/12-make-new-source-code-open), 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](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) -- Default branch should be called "main", not "master" - please see [](../inclusive-language.md) for guidance on how to rename the default branch +- Outside collaborators must not be permitted in private repositories. +- Abuse reporting must be enabled by [accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) +- In line with [inclusive language](../inclusive-language.md) guidance, the default branch must not be named "master" - we suggest "main" - please see our [inclusive language guidance](../inclusive-language.md) for how to rename the default branch. ### Teams setup From 03a825d8b302849f93b38b721272b775c47452dd Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:41:42 +0100 Subject: [PATCH 03/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 2e012984..34f61e95 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -11,7 +11,7 @@ In line with [NCSC guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) it is important to secure your code repository. -This guide describes our minimum set of requirements to secure & configure our Github repositories. This minimum set should be implemented alongside other relevant ones that contribute to [security](security.md) as a whole. These are discussed in more detail as part of the [Quality Checks](../quality-checks.md). +This guide describes our minimum set of requirements to secure & configure our Github repositories. This minimum set should be implemented alongside other relevant guidance which contribute to [security](security.md) as a whole. These are discussed in more detail as part of the [Quality Checks](../quality-checks.md). ## Access controls From 26438087164ed70c224da0a773e48d5ccc138bea Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:42:25 +0100 Subject: [PATCH 04/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 34f61e95..d6d950a9 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -11,7 +11,7 @@ In line with [NCSC guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) it is important to secure your code repository. -This guide describes our minimum set of requirements to secure & configure our Github repositories. This minimum set should be implemented alongside other relevant guidance which contribute to [security](security.md) as a whole. These are discussed in more detail as part of the [Quality Checks](../quality-checks.md). +This guide describes our minimum set of requirements to secure & configure our Github repositories. This minimum set should be implemented alongside other relevant guidance which contribute to [security](security.md) as a whole. Please also see [Quality Checks](../quality-checks.md). ## Access controls From 5a01183bf636d8c156c95dad5a7acb004439ea17 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:43:01 +0100 Subject: [PATCH 05/31] Update securing-repositories.md --- practices/securing-repositories.md | 1 - 1 file changed, 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index d6d950a9..43c66b38 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -1,7 +1,6 @@ # Securing repositories - [Securing repositories](#securing-repositories) - - [Prerequisites](#prerequisites) - [Access controls](#access-controls) - [Organisation-level settings](#organisation-level-settings) - [Repository-specific settings](#repository-specific-settings) From fbab32272a77ff81ea9917c8409487281e433666 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:43:54 +0100 Subject: [PATCH 06/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 43c66b38..f9da69bc 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -26,7 +26,7 @@ This guide describes our minimum set of requirements to secure & configure our G - Private repositories must disable forking. - Outside collaborators must not be permitted in private repositories. - Abuse reporting must be enabled by [accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) -- In line with [inclusive language](../inclusive-language.md) guidance, the default branch must not be named "master" - we suggest "main" - please see our [inclusive language guidance](../inclusive-language.md) for how to rename the default branch. +- In line with our [inclusive language guidance](../inclusive-language.md), the default branch must not be named "master" - we suggest "main" - please see our [inclusive language guidance](../inclusive-language.md) for how to rename the default branch. ### Teams setup From 70932cfd38bc62bc1d4ab593dfded853461a6673 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:45:30 +0100 Subject: [PATCH 07/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index f9da69bc..e85a989a 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -30,7 +30,7 @@ This guide describes our minimum set of requirements to secure & configure our G ### Teams setup -Because of baseline visibility configurations, you must setup GitHub teams in order to provide team members access to repositories. The minimum recommended setup is as follows: +Because of baseline visibility configuration (please see Organisation-level settings, above), you must create GitHub teams in to provide individuals access to repositories. 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 one child team within the team, for admins only (e.g. `Engineering Quality Framework Admins`). Add admins only to this team. From 9f2f77c96fc5fc61b4d65bb8cc91636fbc88b77b Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:47:13 +0100 Subject: [PATCH 08/31] Update securing-repositories.md --- practices/securing-repositories.md | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index e85a989a..a799feda 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -27,19 +27,13 @@ This guide describes our minimum set of requirements to secure & configure our G - Outside collaborators must not be permitted in private repositories. - Abuse reporting must be enabled by [accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) - In line with our [inclusive language guidance](../inclusive-language.md), the default branch must not be named "master" - we suggest "main" - please see our [inclusive language guidance](../inclusive-language.md) for how to rename the default branch. - -### Teams setup - -Because of baseline visibility configuration (please see Organisation-level settings, above), you must create GitHub teams in to provide individuals access to repositories. 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 one child team within the team, for admins only (e.g. `Engineering Quality Framework Admins`). Add admins only to this team. -- Create a second child team, for code owners (e.g. `Engineering Quality Framework Code Owners`). Add relevant members to this team, and reference in the CODEOWNERS file (example [here](https://github.com/NHSDigital/software-engineering-quality-framework/blob/master/.github/CODEOWNERS)). -- 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. - -Child teams inherit the parent's access permissions, simplifying permissions management for large groups. Members of child teams also receive notifications when the parent team is `@mentioned`, simplifying communication with multiple groups of people. - -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 repositories. +- GitHub teams must be created to provide individuals access to repositories. 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 one child team within the team, for admins only (e.g. `Engineering Quality Framework Admins`). Add admins only to this team. + - Create a second child team, for code owners (e.g. `Engineering Quality Framework Code Owners`). Add relevant members to this team, and reference in the CODEOWNERS file (example [here](https://github.com/NHSDigital/software-engineering-quality-framework/blob/master/.github/CODEOWNERS)). + - 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. + - Child teams inherit the parent's access permissions, simplifying permissions management for large groups. Members of child teams also receive notifications when the parent team is `@mentioned`, simplifying communication with multiple groups of people. + - 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 repositories. ## Code security From 46a8fe8fa95f3e56f86d1fae70ac41113465cb8a Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:51:31 +0100 Subject: [PATCH 09/31] Update securing-repositories.md --- practices/securing-repositories.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index a799feda..05671e2b 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -28,12 +28,17 @@ This guide describes our minimum set of requirements to secure & configure our G - Abuse reporting must be enabled by [accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) - In line with our [inclusive language guidance](../inclusive-language.md), the default branch must not be named "master" - we suggest "main" - please see our [inclusive language guidance](../inclusive-language.md) for how to rename the default branch. - GitHub teams must be created to provide individuals access to repositories. 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 one child team within the team, for admins only (e.g. `Engineering Quality Framework Admins`). Add admins only to this team. - - Create a second child team, for code owners (e.g. `Engineering Quality Framework Code Owners`). Add relevant members to this team, and reference in the CODEOWNERS file (example [here](https://github.com/NHSDigital/software-engineering-quality-framework/blob/master/.github/CODEOWNERS)). - - 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. + - Create a team for the repo (e.g. `Engineering Quality Framework`). + - Add all required members to this team. + - Set this team to have `Write` access (under the `Manage Access` option in `Settings`). + - Create a child team, for admins only (e.g. `Engineering Quality Framework Admins`). + - Add admins only to this team. + - Set this team to have `Admin` access (under the `Manage Access` option in `Settings`). + - Create a second child team, for code owners (e.g. `Engineering Quality Framework Code Owners`). + - Add relevant members to this team. + - Use this team rather than individual accounts in the CODEOWNERS file (example [here](https://github.com/NHSDigital/software-engineering-quality-framework/blob/master/.github/CODEOWNERS)). - Child teams inherit the parent's access permissions, simplifying permissions management for large groups. Members of child teams also receive notifications when the parent team is `@mentioned`, simplifying communication with multiple groups of people. - - 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 repositories. + - Depending on your use case, you may want to create additional teams (e.g. a read-only access team). ## Code security From cf0a4c8950f9451b3f1813b64661ae9418eeceda Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:52:42 +0100 Subject: [PATCH 10/31] Update securing-repositories.md --- practices/securing-repositories.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 05671e2b..dcd9b25a 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -27,6 +27,9 @@ This guide describes our minimum set of requirements to secure & configure our G - Outside collaborators must not be permitted in private repositories. - Abuse reporting must be enabled by [accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) - In line with our [inclusive language guidance](../inclusive-language.md), the default branch must not be named "master" - we suggest "main" - please see our [inclusive language guidance](../inclusive-language.md) for how to rename the default branch. + +## Teams setup + - GitHub teams must be created to provide individuals access to repositories. The minimum recommended setup is as follows: - Create a team for the repo (e.g. `Engineering Quality Framework`). - Add all required members to this team. From 0ad21f6bd3063adc1c9c3c13b9068b6c1b0ff0cc Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 16:55:17 +0100 Subject: [PATCH 11/31] Update securing-repositories.md --- practices/securing-repositories.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index dcd9b25a..26fd227f 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -45,9 +45,9 @@ This guide describes our minimum set of requirements to secure & configure our G ## Code security -- Enable, at a minimum, [Dependabot](https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/) alerts for vulnerabilities and respond to them appropriately. -- Generate [SBOM (Software Bill of Materials)](../tools/dependency-scan/README.md) for your repository content and all the artefacts that are build as part of the CI/CD process -- Disable ability to push to the default branch for everyone, admins included (`applies-to-admin` option). +- [Dependabot](https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/) alerts for vulnerabilities must be enabled and acted on appropriately. +- [SBOM (Software Bill of Materials)](../tools/dependency-scan/README.md) must be generated for your repository content and all the artefacts that are build as part of the CI/CD process. +- Ability to push to the default branch must be disabled for everyone, including administrators (using the `applies-to-admin` option). - Refer to [Quality Checks](../quality-checks.md) for further code security practices. ### Branch protection From 7073de0c7c02fa409d35b8d37a85c2d2da4ef315 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:00:37 +0100 Subject: [PATCH 12/31] Update securing-repositories.md --- practices/securing-repositories.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 26fd227f..a38a3921 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -52,7 +52,10 @@ This guide describes our minimum set of requirements to secure & configure our G ### Branch protection -- Require [pull request code reviews](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging), by at least one code owner, to merge a branch. -- Require [signed commits](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#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](guides/commit-signing.md) 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. +- Require [Pull request code reviews](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging), must be required to merge a branch. + - Code reviews must be approved by at least one code owner +- Commits must be [signed](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits), and 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](guides/commit-signing.md) for macOS, Windows, GitHub Actions, and AWS CodePipeline. +- Existing reviews must be invalidated automatically when new commits are pushed (using the `fresh-commits-invalidate-existing-reviews` option). +- Merging must be blocked if the brnach is not up to date. +- Consider any further automated status checks which should be enforced prior to merging a branch From b055837980b10377dad01d95dd973d7a6ccc88d0 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:02:21 +0100 Subject: [PATCH 13/31] Update securing-repositories.md --- practices/securing-repositories.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index a38a3921..92dc1172 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -47,15 +47,15 @@ This guide describes our minimum set of requirements to secure & configure our G - [Dependabot](https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/) alerts for vulnerabilities must be enabled and acted on appropriately. - [SBOM (Software Bill of Materials)](../tools/dependency-scan/README.md) must be generated for your repository content and all the artefacts that are build as part of the CI/CD process. -- Ability to push to the default branch must be disabled for everyone, including administrators (using the `applies-to-admin` option). - Refer to [Quality Checks](../quality-checks.md) for further code security practices. ### Branch protection -- Require [Pull request code reviews](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging), must be required to merge a branch. +- Ability to push to the default branch must be disabled for everyone, including administrators (using the `applies-to-admin` option). +- Pull request [code reviews](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging) must be required prior to merging a branch. - Code reviews must be approved by at least one code owner - Commits must be [signed](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits), and 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](guides/commit-signing.md) for macOS, Windows, GitHub Actions, and AWS CodePipeline. - Existing reviews must be invalidated automatically when new commits are pushed (using the `fresh-commits-invalidate-existing-reviews` option). -- Merging must be blocked if the brnach is not up to date. +- Merging must be blocked if the branch is not up to date. - Consider any further automated status checks which should be enforced prior to merging a branch From 0bfb6a8740f2b63158dd222536e668f00265a96b Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:04:16 +0100 Subject: [PATCH 14/31] Update securing-repositories.md --- practices/securing-repositories.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 92dc1172..95231613 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -10,7 +10,9 @@ In line with [NCSC guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) it is important to secure your code repository. -This guide describes our minimum set of requirements to secure & configure our Github repositories. This minimum set should be implemented alongside other relevant guidance which contribute to [security](security.md) as a whole. Please also see [Quality Checks](../quality-checks.md). +This guide describes our minimum set of requirements to secure & configure our code repositories, with specific guidance for GitHub-based repositories. + +This minimum set of requirements should be implemented alongside other relevant guidance which contribute to [security](security.md) as a whole. Please also see [Quality Checks](../quality-checks.md). ## Access controls From 29d0c71bcbc112446d6127448c2b2fd22d6e6593 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:06:18 +0100 Subject: [PATCH 15/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 95231613..957e30cd 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -40,7 +40,7 @@ This minimum set of requirements should be implemented alongside other relevant - Add admins only to this team. - Set this team to have `Admin` access (under the `Manage Access` option in `Settings`). - Create a second child team, for code owners (e.g. `Engineering Quality Framework Code Owners`). - - Add relevant members to this team. + - Add relevant members to this team: these are the individuals who will be permitted to approve pull request code reviews (please see Branch protection, below). - Use this team rather than individual accounts in the CODEOWNERS file (example [here](https://github.com/NHSDigital/software-engineering-quality-framework/blob/master/.github/CODEOWNERS)). - Child teams inherit the parent's access permissions, simplifying permissions management for large groups. Members of child teams also receive notifications when the parent team is `@mentioned`, simplifying communication with multiple groups of people. - Depending on your use case, you may want to create additional teams (e.g. a read-only access team). From cffce680fd65b5ec6cb95b4b0e07024f49d51998 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:07:35 +0100 Subject: [PATCH 16/31] Update securing-repositories.md --- practices/securing-repositories.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 957e30cd..1b79a530 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -55,7 +55,8 @@ This minimum set of requirements should be implemented alongside other relevant - Ability to push to the default branch must be disabled for everyone, including administrators (using the `applies-to-admin` option). - Pull request [code reviews](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging) must be required prior to merging a branch. - - Code reviews must be approved by at least one code owner + - Code reviews must be approved by at least one code owner. + - You may want to require multiple code owners to review pull requests. - Commits must be [signed](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits), and 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](guides/commit-signing.md) for macOS, Windows, GitHub Actions, and AWS CodePipeline. - Existing reviews must be invalidated automatically when new commits are pushed (using the `fresh-commits-invalidate-existing-reviews` option). From e4db996d312a27c3c62ddee27be05f3b34f67f6c Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:07:56 +0100 Subject: [PATCH 17/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 1b79a530..0ea7a383 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -57,7 +57,7 @@ This minimum set of requirements should be implemented alongside other relevant - Pull request [code reviews](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging) must be required prior to merging a branch. - Code reviews must be approved by at least one code owner. - You may want to require multiple code owners to review pull requests. -- Commits must be [signed](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits), and verified before merging. +- Commits must be [signed](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits) and 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](guides/commit-signing.md) for macOS, Windows, GitHub Actions, and AWS CodePipeline. - Existing reviews must be invalidated automatically when new commits are pushed (using the `fresh-commits-invalidate-existing-reviews` option). - Merging must be blocked if the branch is not up to date. From 32453141213a05727d6340b75b275a17d6afa51c Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:08:49 +0100 Subject: [PATCH 18/31] Update securing-repositories.md --- practices/securing-repositories.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 0ea7a383..f2b9b4f5 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -58,7 +58,8 @@ This minimum set of requirements should be implemented alongside other relevant - Code reviews must be approved by at least one code owner. - You may want to require multiple code owners to review pull requests. - Commits must be [signed](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits) and 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](guides/commit-signing.md) for macOS, Windows, GitHub Actions, and AWS CodePipeline. + - 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. + - For further details, please see [Setup Guides](guides/commit-signing.md) for macOS, Windows, GitHub Actions, and AWS CodePipeline. - Existing reviews must be invalidated automatically when new commits are pushed (using the `fresh-commits-invalidate-existing-reviews` option). - Merging must be blocked if the branch is not up to date. - Consider any further automated status checks which should be enforced prior to merging a branch From e7c4973fd61ae634ee5e058285269f3458194810 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:15:21 +0100 Subject: [PATCH 19/31] Update securing-repositories.md --- practices/securing-repositories.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index f2b9b4f5..84cbcfcc 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -30,7 +30,17 @@ This minimum set of requirements should be implemented alongside other relevant - Abuse reporting must be enabled by [accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) - In line with our [inclusive language guidance](../inclusive-language.md), the default branch must not be named "master" - we suggest "main" - please see our [inclusive language guidance](../inclusive-language.md) for how to rename the default branch. -## Teams setup +### Repository content + +- The following minimum set of files must be included in the repository, to support others to navigate the repository content: + - README.md + - CONTRIBUTING.md + - LICENSE.md + - Pull request template + - Security issue report note +- We recommend the use of a repository template, for example [NHS England Repository Template](https://github.com/nhs-england-tools/repository-template) + +### Teams setup - GitHub teams must be created to provide individuals access to repositories. The minimum recommended setup is as follows: - Create a team for the repo (e.g. `Engineering Quality Framework`). From 1589d3f73571e1f6d033a19ddea5d9b9ddc9d568 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:16:11 +0100 Subject: [PATCH 20/31] Update securing-repositories.md --- practices/securing-repositories.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 84cbcfcc..5ce2e3f1 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -30,16 +30,6 @@ This minimum set of requirements should be implemented alongside other relevant - Abuse reporting must be enabled by [accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository) - In line with our [inclusive language guidance](../inclusive-language.md), the default branch must not be named "master" - we suggest "main" - please see our [inclusive language guidance](../inclusive-language.md) for how to rename the default branch. -### Repository content - -- The following minimum set of files must be included in the repository, to support others to navigate the repository content: - - README.md - - CONTRIBUTING.md - - LICENSE.md - - Pull request template - - Security issue report note -- We recommend the use of a repository template, for example [NHS England Repository Template](https://github.com/nhs-england-tools/repository-template) - ### Teams setup - GitHub teams must be created to provide individuals access to repositories. The minimum recommended setup is as follows: @@ -73,3 +63,13 @@ This minimum set of requirements should be implemented alongside other relevant - Existing reviews must be invalidated automatically when new commits are pushed (using the `fresh-commits-invalidate-existing-reviews` option). - Merging must be blocked if the branch is not up to date. - Consider any further automated status checks which should be enforced prior to merging a branch + +## Repository content + +- The following minimum set of files must be included in the repository, to support others to navigate the repository content: + - README.md + - CONTRIBUTING.md + - LICENSE.md + - Pull request template + - Security issue report note +- We recommend the use of a repository template, for example [NHS England Repository Template](https://github.com/nhs-england-tools/repository-template) From ae8788f2ac7e6aca9beeac5f3903aea43bcfe5af Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:16:56 +0100 Subject: [PATCH 21/31] Update securing-repositories.md --- practices/securing-repositories.md | 1 + 1 file changed, 1 insertion(+) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 5ce2e3f1..51c8e160 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -7,6 +7,7 @@ - [Teams setup](#teams-setup) - [Code security](#code-security) - [Branch protection](#branch-protection) + - [Repository content](#repository-content) In line with [NCSC guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) it is important to secure your code repository. From 4d985809994ec53392c7fbcd9b406a20b7ea004b Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:18:50 +0100 Subject: [PATCH 22/31] Update securing-repositories.md --- practices/securing-repositories.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 51c8e160..88ae3f97 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -71,6 +71,6 @@ This minimum set of requirements should be implemented alongside other relevant - README.md - CONTRIBUTING.md - LICENSE.md - - Pull request template - - Security issue report note + - .github/PULL_REQUEST_TEMPLATE.md + - .github/SECURITY.md - We recommend the use of a repository template, for example [NHS England Repository Template](https://github.com/nhs-england-tools/repository-template) From 5af1a100fc217b369f3568fbd26fc8bdddea1597 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:22:25 +0100 Subject: [PATCH 23/31] Update securing-repositories.md --- practices/securing-repositories.md | 1 + 1 file changed, 1 insertion(+) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 88ae3f97..ef57f177 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -67,6 +67,7 @@ This minimum set of requirements should be implemented alongside other relevant ## Repository content +- The repository must have a description(using the `About` option) - The following minimum set of files must be included in the repository, to support others to navigate the repository content: - README.md - CONTRIBUTING.md From 1ef772ffd3ec109476105444eb61cb6550e8ceb4 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 17:22:39 +0100 Subject: [PATCH 24/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index ef57f177..2744fc3b 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -67,7 +67,7 @@ This minimum set of requirements should be implemented alongside other relevant ## Repository content -- The repository must have a description(using the `About` option) +- The repository must have a description (using the `About` option) - The following minimum set of files must be included in the repository, to support others to navigate the repository content: - README.md - CONTRIBUTING.md From 73cb46d5ef337b2e7e141dea759158531404d2bb Mon Sep 17 00:00:00 2001 From: andyblundell Date: Mon, 14 Aug 2023 19:31:33 +0100 Subject: [PATCH 25/31] Update securing-repositories.md --- practices/securing-repositories.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 2744fc3b..55bbe53a 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -72,6 +72,7 @@ This minimum set of requirements should be implemented alongside other relevant - README.md - CONTRIBUTING.md - LICENSE.md - - .github/PULL_REQUEST_TEMPLATE.md - - .github/SECURITY.md + - PULL_REQUEST_TEMPLATE.md + - SECURITY.md + - CODEOWNERS (which should reference teams rather than individuals - please see [teams setup](#teams-setup) - We recommend the use of a repository template, for example [NHS England Repository Template](https://github.com/nhs-england-tools/repository-template) From d0cd6afd787a42318a89e75fc5733d1bd9552c0f Mon Sep 17 00:00:00 2001 From: andyblundell Date: Tue, 15 Aug 2023 08:18:25 +0100 Subject: [PATCH 26/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 55bbe53a..918d7182 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -9,7 +9,7 @@ - [Branch protection](#branch-protection) - [Repository content](#repository-content) -In line with [NCSC guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) it is important to secure your code repository. +In line with [NCSC guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) it is essential to secure your code repository. This guide describes our minimum set of requirements to secure & configure our code repositories, with specific guidance for GitHub-based repositories. From a692f5e336d6b2b8019a7ae97f204c2dbfb4d366 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Tue, 15 Aug 2023 08:20:17 +0100 Subject: [PATCH 27/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 918d7182..0b684c9f 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -11,7 +11,7 @@ In line with [NCSC guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) it is essential to secure your code repository. -This guide describes our minimum set of requirements to secure & configure our code repositories, with specific guidance for GitHub-based repositories. +This guide describes our minimum set of requirements to secure & configure our code repositories, with specific guidance for GitHub-based repositories. Note: these requirements apply to all repositories, not only those hosted on GitHub. This minimum set of requirements should be implemented alongside other relevant guidance which contribute to [security](security.md) as a whole. Please also see [Quality Checks](../quality-checks.md). From 67dd547b75ef7e95617fa18514216ed9d3ac5b1e Mon Sep 17 00:00:00 2001 From: andyblundell Date: Tue, 15 Aug 2023 08:23:29 +0100 Subject: [PATCH 28/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 0b684c9f..14b758f5 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -68,7 +68,7 @@ This minimum set of requirements should be implemented alongside other relevant ## Repository content - The repository must have a description (using the `About` option) -- The following minimum set of files must be included in the repository, to support others to navigate the repository content: +- The following minimum set of files must be included in the repository, to support others to navigate the repository: - README.md - CONTRIBUTING.md - LICENSE.md From 2ca6ae9c30821d7870267a4253ca2cab0b972423 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Thu, 9 Nov 2023 14:28:11 +0000 Subject: [PATCH 29/31] Rewording on commit signing --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 14b758f5..4d3e185d 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -59,7 +59,7 @@ This minimum set of requirements should be implemented alongside other relevant - Code reviews must be approved by at least one code owner. - You may want to require multiple code owners to review pull requests. - Commits must be [signed](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits) and 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. + - Git treats authentication and identity separately - without a signature, a git commit could have come from anyone, and the email address attached to a commit can be made up. A compromised junior account can apply the lead developer's email address to a bad commit in the hope of an easy merge to `main`. When github verifies the signature of a commit before a merge, it tells us that it was committed by who it claims to have been signed by. It may legitimately be uploaded by someone else but as long as github can verify the signature, we can be sure of the authorship. - For further details, please see [Setup Guides](guides/commit-signing.md) for macOS, Windows, GitHub Actions, and AWS CodePipeline. - Existing reviews must be invalidated automatically when new commits are pushed (using the `fresh-commits-invalidate-existing-reviews` option). - Merging must be blocked if the branch is not up to date. From 7786faf72349f1857e78a9e1b6e8129e4cd47f34 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Thu, 16 Nov 2023 12:33:19 +0000 Subject: [PATCH 30/31] Update securing-repositories.md Added 3659ffd "removing sensitive information" back in as the merge conflict had become confused --- practices/securing-repositories.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 4d3e185d..856a3e76 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -65,6 +65,10 @@ This minimum set of requirements should be implemented alongside other relevant - Merging must be blocked if the branch is not up to date. - Consider any further automated status checks which should be enforced prior to merging a branch +### Removing sensitive information + +Teams should take all necessary precautions to ensure that sensitive data does not leak into Source Control Management Systems. Should any sensitive information leak into Source Control then teams should review the steps [detailed here](guides/commit-purge.md). + ## Repository content - The repository must have a description (using the `About` option) From e132978dc556b7843df6259ac952f8667b82dc81 Mon Sep 17 00:00:00 2001 From: andyblundell Date: Thu, 16 Nov 2023 12:46:52 +0000 Subject: [PATCH 31/31] Update securing-repositories.md --- practices/securing-repositories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index 856a3e76..017c72ec 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -49,7 +49,7 @@ This minimum set of requirements should be implemented alongside other relevant ## Code security - [Dependabot](https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/) alerts for vulnerabilities must be enabled and acted on appropriately. -- [SBOM (Software Bill of Materials)](../tools/dependency-scan/README.md) must be generated for your repository content and all the artefacts that are build as part of the CI/CD process. +- [SBOM (Software Bill of Materials)](../tools/dependency-scan/README.md) must be generated for your repository content and all the artefacts that are built as part of the CI/CD process. - Refer to [Quality Checks](../quality-checks.md) for further code security practices. ### Branch protection