Improve documentation around Repository visibility

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 `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 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
+
+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 individual Organisation but who are members of the Enterprise.

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 `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](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 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 <!-- markdown-link-check-disable -->[accepting content reports](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-how-contributors-report-abuse-in-your-organizations-repository)<!-- markdown-link-check-enable -->
 
 ### 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