Update to the Secret Auditing page as per discussions in GDS Lead tec…

…hnologists meeting. GitHub secret scanning upgraded to a must. Team must also review alerts and record outcomes.

source/standards/secrets-auditing.html.md.erb

@@ -38,9 +38,14 @@ Your team should:
 - create alerts for use cases of access which may indicate a security breach
   - this should include use of high risk secrets, such as break-glass accounts or root
 - look for any opportunities to replace secrets with ephemeral tokens, such as moving from hard coded AWS secrets in GitHub Actions to using OpenID Connect.
-- consider using [Github's Secret Scanning] features, as well as using their [Partner Program] features
 - consider whether your use of secrets can be reduced by relying on e.g. automated CI/CD processes (such as Terraform etc)
 
+Your team must:
+
+- use [Github's Secret Scanning], and consider using their [Partner Program] features
+- review the alerts on a regular basis, for example as part of the normal planning and prioritisation process
+- ensure that the outcome of each alert is recorded, even if it is closed as a false positive
+
 You should be conscious of the impacts of automated secrets rotation on service users. There may also be legal/contractual obligations to consider if you are changing how you manage user secrets.
 
 [Github's Secret Scanning]: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning