---
{
  "title": "Secrets management",
  "summary": "Manage credential ownership, distribution, rotation, revocation, and leaked copies across source history, deployment artifacts, logs, and runtime consumers.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    9
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: Secrets Management",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---
## What it means

Secrets management controls the creation, storage, delivery, use, rotation, and revocation of credentials such as API keys. A central store can help, but access policies and application behavior still determine exposure. Secret values should not spread into source history, logs, build outputs, or unnecessary services.

## A practical example

A deployment retrieves a narrowly scoped service credential through an approved mechanism rather than embedding it in source. The team records an owner, tests rotation, and knows which consumers must stop using the value when it is revoked.

## What to check

Inventory secret owners and consumers, limit access, audit retrieval where appropriate, and test rotation and revocation. Inspect logs and artifacts for unintended copies and prefer shorter-lived credentials when supported.

## A common pitfall

Deleting a leaked value from the latest source file does not revoke it or erase existing copies. Treat disclosure as a credential incident and address every affected consumer.

## Think it through

What comes before celebrating removal of a leaked API key from Git?

**Answer:** Revoke or rotate the exposed credential and investigate where it was used or copied.

## Follow a secret through its consumers

Imagine a fictional academy's schedule integration uses an API key. The key can appear in deployment configuration, process memory, diagnostic output, and accidental developer copies. A central store helps distribution, but it does not automatically prevent those downstream exposures.

Record who owns the credential, which systems need it, what authority it grants, and how replacement reaches every consumer. A secret without a current owner becomes difficult to rotate during an incident.

## Rotation is an operational change

Suppose the provider issues a replacement key. Updating one deployment may leave an old worker or scheduled task using the earlier value. Plan the supported overlap, validation, and revocation behavior according to the service's actual capabilities.

Short-lived credentials can reduce the duration of some exposure, but they still require controlled issuance and appropriate scope. A briefly valid administrator credential can cause durable effects while it is usable.

## A leak needs more than source cleanup

Deleting the key from a current file does not invalidate copies in history, artifacts, or someone else's checkout. Treat the credential as exposed, replace or revoke it, and investigate its relevant usage with the appropriate records.

For a safe exercise, draw a mock key's path from issuance to two application consumers. Simulate rotation using invented values and verify that both consumers switch before the old value is retired. Add a fictitious log leak and state the response sequence. This tests credential lifecycle and recovery without placing real secrets in a tutorial, issue, screenshot, or repository.

## Related concepts

- [[key-management]]
- [[least-privilege]]
- [[incident-response]]