From 5427f77d3b8f977a975e0ea6607884bc9e16f797 Mon Sep 17 00:00:00 2001 From: walteck Date: Mon, 5 Feb 2024 20:28:05 +0000 Subject: [PATCH 01/13] Update baseline visibility and securing repositories practices --- practices/baseline-visibility.md | 23 +++++++++++++++++++++++ practices/securing-repositories.md | 8 ++++---- 2 files changed, 27 insertions(+), 4 deletions(-) create mode 100644 practices/baseline-visibility.md diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md new file mode 100644 index 00000000..52f50d83 --- /dev/null +++ b/practices/baseline-visibility.md @@ -0,0 +1,23 @@ +# Baseline Visibility + +## Collaborating + +This repository is part of the [NHSDigital GitHub Organisation](https://github.com/NHSDigital), this organisation in turn forms part of a wider [Enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-for-enterprises). To enable effective collaboration between members of the NHSDigital organisation the [base permissions](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization) for all repositories should be set to `Read`. This will mean that individual members will be able to view source code from across the organisation whether it is Public or Private. + +As the organisation is part of the Enterprise there are other Organisations, for members of these organisations it is possible to provide access to view Source Code in this organisation without the need to invite users into this org by setting the visibility for the repository to [Internal](./baseline-visibility.md#internal-repositories). + +## Contributing + +With these permissions members can view the source code, they might then be able to identify improvements to this code. Each repository should contain a [CONTRIBUTING.md](../CONTRIBUTING.md) to describe how both team members and members from the wider organisation can contribute to the repository. Contributions to repositories are welcomed and should be encouraged. + +## Code Owners + +Each repository should include a [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file in the root of the project. And [branch protections](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) must be in place to ensure that any Pull Requests are approved by users listed in the codeowners file. This ensures that any code changes are approved by appropriate members of staff from the teams that own and are responsible for the code and any downstream services that depend upon it. + +Teams can be listed as CODEOWNERS - but secret teams should not be used so that individual members of the organisation can identify who the codeowners are. + +The presence of the CodeOwners file will also mean that organisation members can identify who to contact should they have any questions about the code. + +## Internal Repositories + +Private repositories can be created at the `Internal` type. This will mean that all members of the "Enterprise" can view these repositories. Note that this will include users who do not have direct access to the NHSDigital Organisation. diff --git a/practices/securing-repositories.md b/practices/securing-repositories.md index da07c41b..40381450 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -28,19 +28,19 @@ Contributors must take all necessary precautions to ensure that sensitive data d ### Organisation-level settings - All users must have MFA enabled. -- Baseline visibility for private repositories must be `No Permission`. +- [Baseline visibility](baseline-visibility.md) for private repositories must be `Read`. - Ability to change repository view from private to public must be reserved to admins only. ### Repository-specific settings - 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. +- [Outside collaborators](outside-collaborators.md) in private repositories must be there for a specific purpose (e.g. Penetration testers) and their need for access must be regularly reviewed. - 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) ### 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 configurations, you must setup GitHub teams in order to provide team members appropriate access to repositories. The minimum recommended setup is as follows: - Create one team with the name of your product (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. @@ -49,7 +49,7 @@ Because of baseline visibility configurations, you must setup GitHub teams in or 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. 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 9f120b2293d94faeab0f1b5ddd411c237cb0a464 Mon Sep 17 00:00:00 2001 From: Chris Walters Date: Wed, 19 Mar 2025 09:43:44 +0000 Subject: [PATCH 02/13] reverting change to baseline permission setting --- 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 40381450..45f4daf1 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -28,7 +28,7 @@ Contributors must take all necessary precautions to ensure that sensitive data d ### Organisation-level settings - All users must have MFA enabled. -- [Baseline visibility](baseline-visibility.md) for private repositories must be `Read`. +- [Baseline visibility](baseline-visibility.md) 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 From 9c9a2e1bc27ff76064396d100e41ae0e7de0ccb5 Mon Sep 17 00:00:00 2001 From: Chris Walters Date: Wed, 19 Mar 2025 09:49:12 +0000 Subject: [PATCH 03/13] improving clarity around internal repositories --- practices/baseline-visibility.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index 52f50d83..ffe092df 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -2,13 +2,13 @@ ## Collaborating -This repository is part of the [NHSDigital GitHub Organisation](https://github.com/NHSDigital), this organisation in turn forms part of a wider [Enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-for-enterprises). To enable effective collaboration between members of the NHSDigital organisation the [base permissions](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization) for all repositories should be set to `Read`. This will mean that individual members will be able to view source code from across the organisation whether it is Public or Private. +This repository is part of the [NHSDigital GitHub Organisation](https://github.com/NHSDigital), this organisation in turn forms part of a wider [Enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-for-enterprises). To enable effective collaboration between members of the NHSDigital organisation the [base permissions](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization) for all repositories should be set to `No Permissions`. This will mean that individual members will not be able to view source code from across the organisation for Private repositories, unless granted specific permissions. All members should be invited to the `everyone` team - where repositories are Private, but teams want to provide access to the wider community, specifically the members of the organisation the repository is part of, then this `everyone` team can be used for example to provide `read` permissions to a repository. As the organisation is part of the Enterprise there are other Organisations, for members of these organisations it is possible to provide access to view Source Code in this organisation without the need to invite users into this org by setting the visibility for the repository to [Internal](./baseline-visibility.md#internal-repositories). ## Contributing -With these permissions members can view the source code, they might then be able to identify improvements to this code. Each repository should contain a [CONTRIBUTING.md](../CONTRIBUTING.md) to describe how both team members and members from the wider organisation can contribute to the repository. Contributions to repositories are welcomed and should be encouraged. +With these permissions members can view the source code or Public and Internal repositories, they might then be able to identify improvements to this code. Each repository should contain a [CONTRIBUTING.md](../CONTRIBUTING.md) to describe how both team members and members from the wider organisation can contribute to the repository. Contributions to repositories are welcomed and should be encouraged. ## Code Owners @@ -20,4 +20,4 @@ The presence of the CodeOwners file will also mean that organisation members can ## Internal Repositories -Private repositories can be created at the `Internal` type. This will mean that all members of the "Enterprise" can view these repositories. Note that this will include users who do not have direct access to the NHSDigital Organisation. +Private repositories can be created at the `Internal` type. This will mean that all members of the "Enterprise" can view these repositories. Note that this will include users who do not have direct access to the individual Organisation but who are members of the Enterprise. From f7ca809a37a24c4ab9f9529c7d0a5a48ab031c19 Mon Sep 17 00:00:00 2001 From: Chris Walters Date: Wed, 19 Mar 2025 09:51:50 +0000 Subject: [PATCH 04/13] further clarification improvements --- practices/baseline-visibility.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index ffe092df..73573b15 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -8,7 +8,7 @@ As the organisation is part of the Enterprise there are other Organisations, for ## Contributing -With these permissions members can view the source code or Public and Internal repositories, they might then be able to identify improvements to this code. Each repository should contain a [CONTRIBUTING.md](../CONTRIBUTING.md) to describe how both team members and members from the wider organisation can contribute to the repository. Contributions to repositories are welcomed and should be encouraged. +With these permissions members can view the source code of Public and Internal repositories and Private repositories that they have explicit read permissions for, they might then be able to identify improvements to this code. Each repository should contain a [CONTRIBUTING.md](../CONTRIBUTING.md) to describe how both team members and members from the wider organisation can contribute to the repository. Contributions to repositories are welcomed and should be encouraged. ## Code Owners From 83e72e31e0dae39b6b4df186baed2be08977a24d Mon Sep 17 00:00:00 2001 From: Chris Walters Date: Fri, 28 Mar 2025 09:50:35 +0000 Subject: [PATCH 05/13] removing unnecessary link --- 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 45f4daf1..c9e893e2 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -35,7 +35,7 @@ Contributors must take all necessary precautions to ensure that sensitive data d - 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. -- [Outside collaborators](outside-collaborators.md) in private repositories must be there for a specific purpose (e.g. Penetration testers) and their need for access must be regularly reviewed. +- Outside collaborators in private repositories must be there for a specific purpose (e.g. Penetration testers) and their need for access must be regularly reviewed. - 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) ### Teams setup From d970d92cb0896aa65d5a54c3f2295d1df6057645 Mon Sep 17 00:00:00 2001 From: Dan Stefaniuk <499338+stefaniuk@users.noreply.github.com> Date: Tue, 26 Aug 2025 12:36:21 +0100 Subject: [PATCH 06/13] Update practices/baseline-visibility.md Co-authored-by: Alex Young --- practices/baseline-visibility.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index 73573b15..938d9410 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -2,7 +2,7 @@ ## Collaborating -This repository is part of the [NHSDigital GitHub Organisation](https://github.com/NHSDigital), this organisation in turn forms part of a wider [Enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-for-enterprises). To enable effective collaboration between members of the NHSDigital organisation the [base permissions](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization) for all repositories should be set to `No Permissions`. This will mean that individual members will not be able to view source code from across the organisation for Private repositories, unless granted specific permissions. All members should be invited to the `everyone` team - where repositories are Private, but teams want to provide access to the wider community, specifically the members of the organisation the repository is part of, then this `everyone` team can be used for example to provide `read` permissions to a repository. +This repository is part of the [NHSDigital GitHub Organisation](https://github.com/NHSDigital), which forms part of a wider [Enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-for-enterprises). To enable effective collaboration between members of the NHSDigital organisation the [base permissions](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization) for repositories should be set to `No Permissions`, and visibility of Internal repositories is limited to members of the organisation. This will mean that individual members will not be able to view Private repository source code unless granted specific permissions. All members should be invited to the `everyone` team. This grants access to Internal repositories while keeping Private repository access constrained. As the organisation is part of the Enterprise there are other Organisations, for members of these organisations it is possible to provide access to view Source Code in this organisation without the need to invite users into this org by setting the visibility for the repository to [Internal](./baseline-visibility.md#internal-repositories). From da73a92b739c44adacb12801c1e61442d90c2349 Mon Sep 17 00:00:00 2001 From: Dan Stefaniuk <499338+stefaniuk@users.noreply.github.com> Date: Tue, 26 Aug 2025 12:36:39 +0100 Subject: [PATCH 07/13] Update practices/baseline-visibility.md Co-authored-by: Alex Young --- practices/baseline-visibility.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index 938d9410..52e4b6e0 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -4,7 +4,7 @@ This repository is part of the [NHSDigital GitHub Organisation](https://github.com/NHSDigital), which forms part of a wider [Enterprise](https://docs.github.com/en/enterprise-cloud@latest/admin/overview/about-github-for-enterprises). To enable effective collaboration between members of the NHSDigital organisation the [base permissions](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/setting-base-permissions-for-an-organization) for repositories should be set to `No Permissions`, and visibility of Internal repositories is limited to members of the organisation. This will mean that individual members will not be able to view Private repository source code unless granted specific permissions. All members should be invited to the `everyone` team. This grants access to Internal repositories while keeping Private repository access constrained. -As the organisation is part of the Enterprise there are other Organisations, for members of these organisations it is possible to provide access to view Source Code in this organisation without the need to invite users into this org by setting the visibility for the repository to [Internal](./baseline-visibility.md#internal-repositories). +As the organisation is part of the Enterprise there are other Organisations. Members of these other Organisations have read access to [Internal](./baseline-visibility.md#internal-repositories) repositories. ## Contributing From 1916274ef0ed25f08996b18ddde1156356fd627c Mon Sep 17 00:00:00 2001 From: Dan Stefaniuk <499338+stefaniuk@users.noreply.github.com> Date: Tue, 26 Aug 2025 12:36:49 +0100 Subject: [PATCH 08/13] Update practices/baseline-visibility.md Co-authored-by: Alex Young --- practices/baseline-visibility.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index 52e4b6e0..5ffc687e 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -8,7 +8,7 @@ As the organisation is part of the Enterprise there are other Organisations. Mem ## Contributing -With these permissions members can view the source code of Public and Internal repositories and Private repositories that they have explicit read permissions for, they might then be able to identify improvements to this code. Each repository should contain a [CONTRIBUTING.md](../CONTRIBUTING.md) to describe how both team members and members from the wider organisation can contribute to the repository. Contributions to repositories are welcomed and should be encouraged. +With a baseline of `No Permissions` on a repository and as a member of the `everyone` team, members of the Organisation can view the source code of Public and Internal repositories and Private repositories that they have explicit read permissions for. They might then be able to identify improvements to this code. Each repository should contain a [CONTRIBUTING.md](../CONTRIBUTING.md) to describe how both team members and members from the wider organisation can contribute to the repository. Contributions to repositories are welcomed and should be encouraged. ## Code Owners From 69fccbcd25f11d6c5e2bb45b5c4c5e77482d6b16 Mon Sep 17 00:00:00 2001 From: Dan Stefaniuk <499338+stefaniuk@users.noreply.github.com> Date: Tue, 26 Aug 2025 12:37:03 +0100 Subject: [PATCH 09/13] Update practices/baseline-visibility.md Co-authored-by: Alex Young --- practices/baseline-visibility.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index 5ffc687e..fc9b9213 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -12,7 +12,7 @@ With a baseline of `No Permissions` on a repository and as a member of the `ever ## Code Owners -Each repository should include a [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file in the root of the project. And [branch protections](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) must be in place to ensure that any Pull Requests are approved by users listed in the codeowners file. This ensures that any code changes are approved by appropriate members of staff from the teams that own and are responsible for the code and any downstream services that depend upon it. +Each repository should include a [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file in the root of the project. [Branch protections](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) must be in place to ensure that any Pull Requests are approved by users listed in the CODEOWNERS file. This ensures that any code changes are approved by appropriate members the teams that own and are responsible for the code and any downstream services that depend upon it. Teams can be listed as CODEOWNERS - but secret teams should not be used so that individual members of the organisation can identify who the codeowners are. From d7aca89affbbe76de5139680fa9cb7857927bd80 Mon Sep 17 00:00:00 2001 From: Dan Stefaniuk <499338+stefaniuk@users.noreply.github.com> Date: Tue, 26 Aug 2025 12:37:21 +0100 Subject: [PATCH 10/13] Update practices/baseline-visibility.md Co-authored-by: Alex Young --- practices/baseline-visibility.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index fc9b9213..00294cab 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -14,9 +14,9 @@ With a baseline of `No Permissions` on a repository and as a member of the `ever Each repository should include a [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file in the root of the project. [Branch protections](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) must be in place to ensure that any Pull Requests are approved by users listed in the CODEOWNERS file. This ensures that any code changes are approved by appropriate members the teams that own and are responsible for the code and any downstream services that depend upon it. -Teams can be listed as CODEOWNERS - but secret teams should not be used so that individual members of the organisation can identify who the codeowners are. +The presence of the CODEOWNERS file alows organisation members to identify who to contact should they have any questions about the code. -The presence of the CodeOwners file will also mean that organisation members can identify who to contact should they have any questions about the code. +Teams can be listed as CODEOWNERS, but secret teams should not be used. Otherwise potential contributors wouldn't be able to identify who the codeowners are. ## Internal Repositories From a885473a652beda8d6753b6857b9936db786689e Mon Sep 17 00:00:00 2001 From: Dan Stefaniuk <499338+stefaniuk@users.noreply.github.com> Date: Tue, 26 Aug 2025 12:37:34 +0100 Subject: [PATCH 11/13] Update practices/baseline-visibility.md Co-authored-by: Alex Young --- practices/baseline-visibility.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index 00294cab..ecdbe015 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -20,4 +20,4 @@ Teams can be listed as CODEOWNERS, but secret teams should not be used. Otherwi ## Internal Repositories -Private repositories can be created at the `Internal` type. This will mean that all members of the "Enterprise" can view these repositories. Note that this will include users who do not have direct access to the individual Organisation but who are members of the Enterprise. +Non-public repositories can be created of the `Internal` type. All members of the Enterprise can view these repositories. This will include users who do not have direct access to the individual Organisation but who are members of the Enterprise. From 3eb5fe5dfe3378c09652516f46b730fc2d4a8942 Mon Sep 17 00:00:00 2001 From: Dan Stefaniuk <499338+stefaniuk@users.noreply.github.com> Date: Tue, 26 Aug 2025 12:37:44 +0100 Subject: [PATCH 12/13] Update practices/securing-repositories.md Co-authored-by: Alex Young --- 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 c9e893e2..397d324e 100644 --- a/practices/securing-repositories.md +++ b/practices/securing-repositories.md @@ -35,7 +35,7 @@ Contributors must take all necessary precautions to ensure that sensitive data d - 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. -- Outside collaborators in private repositories must be there for a specific purpose (e.g. Penetration testers) and their need for access must be regularly reviewed. +- Outside collaborators in private repositories must be there for a specific purpose (e.g. security testers) and their need for access must be regularly reviewed. - 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) ### Teams setup From ab7d00435c6d808e3d177a32c88c50b2a27c932c Mon Sep 17 00:00:00 2001 From: Dan Stefaniuk Date: Tue, 26 Aug 2025 12:45:09 +0100 Subject: [PATCH 13/13] Location of the CODEOWNERS file --- practices/baseline-visibility.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/practices/baseline-visibility.md b/practices/baseline-visibility.md index ecdbe015..4af702f0 100644 --- a/practices/baseline-visibility.md +++ b/practices/baseline-visibility.md @@ -12,7 +12,7 @@ With a baseline of `No Permissions` on a repository and as a member of the `ever ## Code Owners -Each repository should include a [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file in the root of the project. [Branch protections](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) must be in place to ensure that any Pull Requests are approved by users listed in the CODEOWNERS file. This ensures that any code changes are approved by appropriate members the teams that own and are responsible for the code and any downstream services that depend upon it. +Each repository should include a [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) file in one of the [recommended locations](https://graphite.dev/guides/in-depth-guide-github-codeowners#creating-and-locating-your-codeowners-file). [Branch protections](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) must be in place to ensure that any Pull Requests are approved by users listed in the CODEOWNERS file. This ensures that any code changes are approved by appropriate members the teams that own and are responsible for the code and any downstream services that depend upon it. The presence of the CODEOWNERS file alows organisation members to identify who to contact should they have any questions about the code.