From 757a332eaa46b8711f9b69d13062dadbaa3e1f21 Mon Sep 17 00:00:00 2001 From: Martyn Inglis Date: Thu, 31 Oct 2024 11:38:02 +0000 Subject: [PATCH] Update to the Secret Auditing page as per discussions in GDS Lead technologists meeting. GitHub secret scanning upgraded to a must. Team must also review alerts and record outcomes. --- source/standards/secrets-auditing.html.md.erb | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/source/standards/secrets-auditing.html.md.erb b/source/standards/secrets-auditing.html.md.erb index d3743320..e26840dc 100644 --- a/source/standards/secrets-auditing.html.md.erb +++ b/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