What is a secret in software, and how should you manage secrets?

Why is putting a key in the code a problem?

Code is copied, shared and kept in version history forever. A key committed even once can be found by anyone who sees the repository, including automated scanners that look for exactly this. Deleting it in a later commit does not remove it from history.

Where should secrets live instead?

The twelve-factor method says configuration that varies between environments belongs in the environment, not in code. For anything sensitive, use a dedicated secrets manager or your platform’s secret store, which encrypts the value, controls who can read it and records access.

What should you do if a secret leaks?

1. Revoke or rotate the secret immediately, before anything else.
2. Check logs for any use of it you did not expect.
3. Remove it from the code and, where practical, from history.
4. Find out how it leaked and close that path.

How do you stop leaks before they happen?

Add secret scanning to the repository and to the pre-commit and pipeline checks, keep local configuration files in the ignore list, and give each service its own credentials so one leak has a small reach. This applies least privilege.

Why rotate secrets?

A secret that never changes stays valuable to an attacker forever. Regular rotation, and short-lived credentials where the platform supports them, limit how long a stolen value remains useful.

Go deeper: CTP™ credential · the TPBOK™ standard · Check your experience

IICTP is an independent technical credentialing body.