Small projects often start with an API key in a local file and end with credentials copied into CI, a hosting dashboard, a teammate’s notes and production logs. The risk is not only where a secret is stored; it is how widely it can act, who can retrieve it, how it reaches the process and how quickly it can be revoked. A manageable system tracks the lifecycle without requiring a large security department.
| Credential | Scope it to | Prefer when available |
|---|---|---|
| Database access | One application, database and required operations | Workload identity or short-lived auth |
| Third-party API key | One integration and minimum endpoint permissions | Provider-managed restricted key |
| CI deployment access | One repository, environment and deployment role | OIDC federation with short-lived credentials |
| Signing key | Specific service and key purpose | KMS/HSM-backed signing where practical |
Keep a non-secret inventory: identifier, owner, consumer, environment, creation date, last rotation, expiry and emergency revocation steps. Never put the value itself in that registry. Separate development, staging and production credentials; a test workflow should not inherit production access just because it is convenient.
Use an ignored local environment file only for local development and provide a placeholder example file with variable names but no values. In production, inject credentials from the platform’s secret facility or retrieve them through an authenticated workload identity at runtime. Do not bake secrets into container images, frontend bundles, build logs, crash reports or URLs.
Masking in CI is a last-resort display control, not protection against a workflow that can exfiltrate a secret. Review who can edit workflows and access deployment environments. Prefer short-lived identity federation for CI-to-cloud access so a long-lived cloud key is not stored in repository settings.
First establish a second credential or a rotation method that supports overlap. Create the new value, deliver it to the consumer, verify successful authentication, then revoke the old one. Monitor authentication failures and keep a bounded rollback window when the provider permits it. Some credentials cannot overlap; document that downtime risk and schedule a tested maintenance procedure rather than assuming rotation is atomic.
Rotate immediately after suspected exposure, staff or vendor changes when access may persist, and according to a risk-based schedule. Rotation without an owner, consumer inventory or proof of revocation can leave zombie credentials active indefinitely.
Know the provider console/API path to disable a key, which services will fail and how to issue a replacement. Rehearse the sequence without exposing the actual value. If a secret lands in a public repository, revoke first; deleting the commit does not erase clones, caches or notifications. Then assess logs and access, replace dependent credentials and document what detection needs improvement.
Secret management is access design plus delivery, rotation and revocation. Track owners and consumers, separate environments, use short-lived workload identity where possible, prevent values from entering code and telemetry, and test replacement before an emergency. A small, accurate inventory and a practiced revoke path beat an unowned “vault” full of forgotten keys.