Secrets management keeps credentials out of source code and gives them a controlled lifecycle. A secret is not only a password. API tokens, database credentials, encryption keys, webhook signing keys, and private certificates all grant an identity or capability when another system accepts them.
How secrets spread through a product
A credential may begin in a local configuration file, then appear in a copied example, a deployment setting, a test fixture, a support message, or command output. Removing the first copy does not invalidate the others. The exposed value remains useful until the system that accepts it rotates or revokes it.
This is especially important when reviewing generated code. A tool can reproduce a value supplied in its context or add a convenient inline placeholder that later receives a real credential. An audit of vibe-coded software looks beyond the current source tree to the paths through which configuration reaches the running application.
| Secret type | Common consumer | Lifecycle question |
|---|---|---|
| API key | External integration | Can it be scoped and revoked? |
| Database credential | Application runtime | Is access limited by environment? |
| Signing key | Session or webhook verifier | How is rotation handled? |
| Certificate key | Service endpoint | Who can export or replace it? |
| Deployment token | Build pipeline | Does each job need the same reach? |
Storage is only one control
Moving a value into an environment variable keeps it out of committed code, but it does not complete secrets management. The deployment platform, logs, error reports, backups, build steps, and administrative interfaces may still expose it. The review follows both the value and the permissions around it.
A complete check covers the lifecycle:
- Inventory: Identify credentials, keys, tokens, and certificates used by each environment.
- Storage: Confirm that committed files and generated artefacts do not contain live values.
- Delivery: Trace how the runtime receives a secret without printing or copying it broadly.
- Scope: Limit what each credential can access and where it can be used.
- Rotation: Replace values without an uncontrolled outage or permanent fallback.
- Revocation: Remove trust when a credential is exposed or no longer needed.
Secrets establish machine identity
Applications use secrets as evidence during authentication. The audit therefore checks whether unrelated services share one identity, whether development credentials can reach production, and whether a long-lived key stands in for a narrower short-lived token. Shared credentials make activity harder to attribute and widen the effect of one disclosure.
Threat modeling helps prioritise values by what they permit rather than by where they were found. A test key with production access is a production secret. A credential stored in a dedicated service may still carry excessive permissions.
What evidence looks like
The audit produces an inventory tied to owners, consumers, environments, and revocation paths. Repository history and build output are checked because deleting a line from the current version does not erase earlier copies. Logs and error handling are reviewed for accidental disclosure. Rotation is verified where the design depends on it.
These checks support the review discipline behind software that is ready to ship. The goal is not a particular storage product. It is a system where a credential has a known purpose, limited reach, controlled distribution, and a tested way to stop trusting it.
