Secrets Management #

Control ID: SDLC-CTRL-0014 | Type: Preventive

Summary #

Build and runtime secrets are stored securely in dedicated secrets management systems, with documented ownership, rotation schedules, and access controls.

Mitigates Risk

SDLC-RISK-0002:

Insider Threat

SDLC-RISK-0004:

Credential and Secret Exposure

SDLC-RISK-0007:

Unauthorised System Access

Description #

Secrets — such as API keys, cryptographic keys, and identity tokens — must be stored securely and documented in a central place. Cryptographic failures are the second highest risk in the OWASP top ten, so rigour and process is essential.

Effective secrets management requires secure storage, strict access controls, regular rotation with expiry monitoring, and clear documentation of each secret’s purpose, ownership, and update procedures. Secrets must be scoped per environment and injected at runtime rather than stored in source code.

Requirements #

All secrets MUST be stored in a dedicated secrets management system, not in source code or configuration files
Secrets MUST be scoped per environment (dev, test, prod)
Secrets MUST be rotated periodically with documented rotation schedules
Expiring secrets MUST trigger automated alerts before expiry
Access to secrets MUST be restricted based on role and environment
Secret access and rotation events MUST be logged for audit purposes
New secrets MUST be documented with ownership, purpose, and update procedures

How we implement this control #

Infrastructure secrets #

We use AWS Secrets Manager to store infrastructure secrets.
Infrastructure secrets are handled with a separate terraform-server repository together with other server information.
The update, creation and deletion of secrets is described in secrets/README.md.
We use a set of helper programs to update the secrets for the different servers. In addition to updating the secrets, the helper program also:
- Tracks which server the secret was updated for.
- When and by whom the secret was updated.
- When does the secret expire.
We have a daily GitHub job that checks if any secret will expire within the next month.
If a secret is going to expire soon a message is sent to our dedicated Slack channel.
Every 3 months we check if any new infrastructure secrets have been added. In the server repository there is a bin/check_new_secrets.sh script that will do the check and tell you if any secrets have been added.
The evidence that we ran the check for new secrets is recorded in the secrets-updated flow.
We have a daily GitHub job that checks if it is more than three months since last time we checked for new secrets.

CI workflow secrets #

We use GitHub Action secrets to store CI workflow secrets.
CI workflow secrets are either repository secrets or organisation secrets.
Organisation and repository secrets are tracked in the secrets repository.
The secrets repository contains a README.md file with general information and one file per secret. Each file gives detailed information about how to get a new secret and how to update them. It also contains:
- When and by whom the secret was updated.
- When does the secret expire.
The secrets repository has a daily GitHub job that checks if:
- any secret will expire within the next month
- any new secrets have been added
If a secret is going to expire soon a message is sent to our dedicated Slack channel.

Compliance Frameworks #

NIST SP 800-53 Rev. 5

IA-5 — Authenticator management — covers the lifecycle of credentials including creation, distribution, storage, rotation, and revocation.
SC-12 — Cryptographic key establishment and management — requires secure generation, distribution, storage, and destruction of cryptographic keys.
SC-28 — Protection of information at rest — secrets must be encrypted at rest in the secrets management system.
AC-3 — Access enforcement — access to secrets must be restricted based on role and environment.
AU-12 — Audit record generation — secret access and rotation events must be logged.

SOC 2 Type II

CC6.1 — Requires protection of credentials and information assets through access controls; secrets management centralises credential storage and access.
CC6.7 — Requires restriction of access credentials to authorised individuals; maps to secret rotation, least-privilege access, and audit logging.
CC6.3 — Requires role-based access to sensitive resources; secrets management enforces that only authorised services and personnel can retrieve credentials.