README file for git-secrets tool (#156)

* README file for git-secrets tool
* Linking to Quality Checks page
* Update security.md

Author: iw-ezequiel

practices/security.md

@@ -67,11 +67,7 @@ The remainder of this page gives more detailed and specific recommendations to b
 - Prevent **[clickjacking](https://sudo.pagerduty.com/for_engineers/#clickjacking)** with `X-Frame-Options`
 - Be careful not to **leak information**, e.g. error messages, stack traces, headers
 - **Don't trust** yourself or others! <a name='secret-scanning'></a>
-  - Code must be automatically scanned for secrets or other sensitive data:
-    - To catch any issues early and to minimise potential exposure, scan code on developer machines *before* code is committed to the code repository. We recommend using [awslabs git-secrets](https://github.com/awslabs/git-secrets). To set this up on a Mac workstation or as part of your Jenkins pipeline, follow the examples and READMEs in [nhsd-git-secrets](../tools/nhsd-git-secrets). Windows testing is in progress and instructions/code will be added in due course
-    - The above solution uses regular expressions to find potential secrets: before using the solution, consider the types of secrets that might exist (based on your technology stack) and update the list of regular expressions as necessary
-    - As a backstop, *also* enable server-side scanning within the code repository. Recommended solution options:
-      - TO DO: more details... for example in [GitHub](https://docs.github.com/en/code-security/secret-security/about-secret-scanning)
+  - Code must be automatically scanned for secrets or other sensitive data. We have a [secret scanning guide](../tools/nhsd-git-secrets/README.md) that describes how to best achieve this using our preferred tooling, and also includes examples to get you started.
   - Be wary of any 3rd party JavaScript included on the page, e.g. for A/B testing, analytics
   - Pin dependencies at known versions to avoid unexpected updates
   - Scan dependencies for vulnerabilities, e.g. using [OWASP Dependency Check](https://www.owasp.org/index.php/OWASP_Dependency_Check) or [Snyk](https://snyk.io/)

tools/nhsd-git-secrets/README.md

@@ -0,0 +1,17 @@
+# Git-Secrets examples
+This folder comprises examples for implementing AWSLabs Git-Secrets, which is our default implementation for [secrets scanning](../../quality-checks.md). As with any default, we expect teams to resolve any caveats as they best see fit, and of course to contribute to these examples.
+
+# Why secrets scanning
+Although we might be re-stating the obvious here, there's two main goals to consistent secrets scanning:
+1. Remove any secrets that may have been checked into the codebase in the past.
+2. Prevent any new secrets from making it into the codebase.
+
+Essentially, we want to avoid the NHS facing [potentially dire consequences](https://www.zdnet.com/article/data-of-243-million-brazilians-exposed-online-via-website-source-code/) due to exposure of secrets.
+
+# How to get started
+If your team isn't doing secrets scanning at all yet, the fundamental first step is to understand the current state of the art. Use the [Macbook](README-mac-workstation.md) or Windows (coming soon...) guides to set up and run Git-Secrets for a nominated team member. Run the tooling, and ascertain whether there's any immediate actions to be taken.
+
+# Getting to green
+Once you've verified there's no urgent actions on your code, the next steps towards getting to green are:
+1. Ensure every team member is doing local scans. Stopping secrets before code has been committed is cheap, removing them from git history is expensive.
+2. Run these same scripts as part of your deployment pipelines as a second line of defence.