Managing secrets outside the repository

Goal

Keep credentials out of places that are copied, shared or indexed, and make replacing a compromised credential a routine operation.

Prerequisites

A place to store secrets with access control (a secrets manager, or at minimum environment files with restrictive permissions on the host) and a deployment path that injects them.

Steps

1. Inventory secrets: database passwords, API keys, signing keys, tokens. Give each an owner and a rotation interval.
2. Remove secrets from the repository history if any are present, then rotate them; a removed commit is not a revoked credential.
3. Inject secrets at runtime through the environment or mounted files, following the twelve-factor separation of config from code; keep an example file with empty values in the repository.
4. Scope credentials narrowly: one per service and environment, least privilege.
5. Never log secrets; build log records from allowed fields, and check that error handlers do not dump request headers or environment.
6. Rehearse rotation so that it is a documented, tested procedure rather than an emergency.

Expected result

A fresh clone contains no credential; a leaked log or backup exposes none; rotation completes without downtime.

Limits and test basis

Environment variables are visible to the process and its children and may be captured by crash reporters; files with strict permissions or a manager are stronger. Secret scanning in CI catches accidents, not design flaws. Guidance follows the cited sources.