Start with consumers, not a vault product
A secret inventory answers which component consumes a secret, what it grants, where it is issued, how it reaches the workload, who approves it, and how it is revoked. Include database passwords, API keys, certificates, signing keys, webhook tokens, bootstrap credentials, backup keys, and machine identities.
Do not store the secret value in the inventory. Store a reference, owner, environment, expiration or rotation expectation, dependency, and recovery implication. This turns a leak report into a bounded response instead of a search through repositories and chat history.
Separate storage from delivery
A secret store, deployment pipeline, runtime injection method, and application configuration are different parts of the path. Map all four. A well-protected store provides little protection if the deployment logs the value, the process exposes it in diagnostics, or a developer copies it into a local file.
Give workloads only the values and permissions they need. Prefer distinct secrets for distinct applications and environments. A single shared credential makes rotation disruptive and prevents an operator from identifying which consumer caused an unexpected use.
Plan bootstrap and rotation
Every secret system has a bootstrap question: how does a new host or deployment process authenticate before it can retrieve runtime credentials? Keep that path narrow, monitored, and separately documented. Emergency access should be controlled and tested, not an old administrator password kept in a wiki.
Rotation needs an owner, sequence, compatibility window, verification, and rollback condition. Where the dependent system permits two active credentials, issue the replacement, update consumers, verify them, then revoke the old one. Test the real applications, not just the secret-store API.
Treat a leak as a response workflow
When a secret appears in a repository, build log, ticket, or message, assume it may be exposed. Identify its scope, rotate or revoke it, investigate use, remove accessible copies where possible, and record the change. Deleting one visible copy is not revocation.
The incident record should add a preventive control: repository scanning, safer pipeline output, shorter-lived credentials, improved access boundary, or clearer ownership. NIST control and SSDF guidance can help structure these practices without replacing product-specific design.
Secret register fields
A register should support rotation and incident response.
| Field | Why it matters | Example evidence |
|---|---|---|
| Consumer | Shows where a replacement must be deployed | Workload or integration name. |
| Privilege | Sets leak impact and least-access review | Database role or API scope. |
| Owner and rotation | Makes action time-bound | Team and scheduled review. |
| Revocation path | Allows a fast containment step | Issuer procedure and test record. |
Questions to answer
Can environment variables be used for secrets?
They can be a delivery mechanism, but review process visibility, logs, diagnostics, deployment records, and host access. Do not treat their presence as a complete secret-management design.
Why avoid a shared production password?
It expands impact, blocks independent rotation, and makes use difficult to attribute. Separate consumers where the technology and operating model allow it.
What proves rotation works?
A test issues a replacement, updates each named consumer, verifies service behaviour, revokes the prior credential, and checks that the old value no longer works.
Inventory, rotate, respond
Record consumers, privilege, issuer, owner, delivery path, expiry, and revocation method.
Replace one bounded credential through a documented sequence and test all consumers.
Contain exposed credentials, inspect use, update the register, and add a control that addresses the leak path.
Operating checks
Make secret handling reviewable.
No-value inventory
The inventory gives responders references and owners without becoming another secret store.
Tested rotation
A production-like exercise covers issuance, deployment, verification, and revocation.
Emergency access
A controlled recovery path is documented, audited, and periodically tested.
