raising visibility of instructions on removing sensitive information (#339)

Author: walteck

README.md

@@ -1,5 +1,7 @@
 # Software Engineering Quality Framework
 
+> **Note:** Contributors must take all necessary precautions to ensure that sensitive data does not leak into Source Control Management Systems. You must ensure you have reviewed the [guidance on what to do should this happen](practices/guides/commit-purge.md).
+
 ## How to get started
 
 See the [Quick Start Guide](quickstart.md)

practices/guides/commit-purge.md

@@ -2,11 +2,21 @@
 
 ## Overview
 
-Engineering teams should take all necessary precautions to ensure that sensitive data does not leak into Source Control Management Systems. This includes secrets being pushed to a remote branch, as well as merging into the default branch. Teams should consider **any** secret posted to a branch of a public repository as compromised and should take necessary steps to revoke and rotate this secret. For Private and Internal repositories teams should still treat leaked credentials as compromised and revoke and rotate them. Teams should also review their Near Miss reporting requirements and ensure that necessary steps are taken. Teams should ensure that a [Secret scanner](https://github.com/NHSDigital/software-engineering-quality-framework/tree/main/tools/nhsd-git-secrets) is enabled on their repositories. Teams must also ensure that developers follow standard processes to ensure any pre-commit hooks are enabled and enforced to reduce the risk of sensitive information being accidentally published. Teams should also contribute to the rule set for these tools as appropriate to ensure secrets are identified correctly.
+There are multiple steps required to ensure sensitive data committed to a GitHub hosted Git repository is fully removed.
+
+Engineering teams must take all necessary precautions to ensure that sensitive data does not leak into Source Control Management Systems. This includes secrets being pushed to a remote branch, as well as merging into the default branch. Teams must consider **any** secret posted to a branch of a public repository as compromised and must take necessary steps to revoke and rotate this secret. For Private and Internal repositories teams must still treat leaked credentials as compromised and revoke and rotate them.
+
+Teams must also review their Near Miss reporting requirements and ensure that necessary steps are taken.
+
+Teams must ensure that a [Secret scanner](https://github.com/NHSDigital/software-engineering-quality-framework/tree/main/tools/nhsd-git-secrets) is enabled on their repositories.
+
+Teams must also ensure that developers follow standard processes to ensure any pre-commit hooks are enabled and enforced to reduce the risk of sensitive information being accidentally published. Teams should also contribute to the rule set for these tools to ensure secrets are identified correctly.
 
 If a secret or other sensitive information is identified as having been pushed to a remote repository in GitHub then the following steps ***must*** be undertaken to ensure removal of the information. Please note that just removing the data from the git history is **not** sufficient as views can be cached by the UI.
 
-1. Rotate the secrets that have been revealed – whether the repository is public or private this should be a key step in reducing the risk of any accidental publishing of secrets.
-2. Consider whether an incident should be raised, for example has sensitive information been shared in a public repository. If in doubt raise an incident following your internal processes.
+### Remediation Steps
+
+1. Rotate the secrets that have been revealed – whether the repository is public or private this is a key step in reducing the risk of any accidental publishing of secrets.
+2. A security incident **must** be raised for all sensitive date committed. This ensures that our Cyber teams can support in assessing the level of risk of the exposure. Contributors must raise an incident following your internal processes.
 3. Undertake steps to [remove the sensitive data from your Git history](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository#purging-a-file-from-your-repositorys-history).
 4. Once the history has been cleansed we need to request that GitHub purge their cache – please [raise a request](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository#fully-removing-the-data-from-github) with the internal Github admins mailbox.

practices/securing-repositories.md

@@ -1,17 +1,21 @@
 # Securing repositories
 
 - [Securing repositories](#securing-repositories)
+  - [Removing sensitive information](#removing-sensitive-information)
   - [Prerequisites](#prerequisites)
   - [Access controls](#access-controls)
     - [Organisation-level settings](#organisation-level-settings)
     - [Repository-specific settings](#repository-specific-settings)
     - [Teams setup](#teams-setup)
   - [Code security](#code-security)
     - [Branch protection](#branch-protection)
-    - [Removing sensitive information](#removing-sensitive-information)
 
 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).
 
+## Removing sensitive information
+
+Contributors must 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 must follow the steps [detailed here](guides/commit-purge.md).
+
 ## 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:
@@ -60,7 +64,3 @@ Depending on your use case, you may want to create additional teams (e.g. a read
 - Require <!-- markdown-link-check-disable -->[signed commits](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-signed-commits)<!-- markdown-link-check-enable -->, 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 (`Dismiss stale pull request approvals when new commits are pushed` option).
 - Require adequate automated status checks prior to merging. This should always include checking that branches are up to date.
-
-### 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).