Skip to main content

The GDS Way and its content is intended for internal use by the GDS and CO CDIO communities.

Secret Auditing

Secrets are digital keys, certificates or credentials such as passwords, SSH keys and tokens. They’re used for managing access permissions, encryption and decryption.

Ideally, each secret is:

  • created for a particular purpose
  • created for a particular entity (a person, machine or task)
  • only valid for a set period of time

These parameters may not be practical in all the use cases, especially when the secrets management is a manual process, so we need auditing to know who accessed which secrets, and when.

When to carry out a secrets audit

You may wish to carry out secrets auditing if you want to:

  • understand who has access to which secrets, and evaluate whether this is appropriate for your security model
  • be able to provide evidence someone has gained access to some secrets to understand the impact of a security breach
  • have confidence in rotating secrets
  • see who has encrypted or decrypted a secret
  • create alerts when sensitive secrets are being accessed

How to carry out a secrets audit

Your team should:

  • log any changes to your access control list (ACL) and capture any deviations from your default, or expected access, ideally in Splunk
  • automate the logging of secrets during the secrets life cycle, from generating secrets to rotating and destroying the secrets, if possible
  • create alerts for use cases of access which may indicate a security breach
  • look for any opportunities to replace secrets with ephemeral tokens, such as moving from hard coded AWS secrets in GitHub Actions to using Open ConnectID.
This page was last reviewed on 21 September 2022. It needs to be reviewed again on 21 March 2023 by the page owner #gds-way .
This page was set to be reviewed before 21 March 2023 by the page owner #gds-way. This might mean the content is out of date.