Where secrets live, and where they never do
A credential committed to a repository is a credential you have to assume is public. Keeping secrets out of the codebase, and out of human hands, is a design decision made once and enforced everywhere.
Infrastructure Practice
A secret that lands in a code repository has, for practical purposes, escaped. It is copied to every clone, preserved in history long after it is deleted from the latest commit, and exposed to everyone who can read the project. The only safe assumption is that a committed credential is a compromised one. So the rule is absolute: secrets never touch the repo.
Managed, short-lived, and fetched at runtime
Credentials live in a managed secrets store, not in files, not in values baked into a pipeline, not in a developer's notes. The application reads them at runtime through an adapter, and the identities that grant access are short-lived rather than standing. A credential that exists for minutes and is scoped to one task is a far smaller prize than a long-lived key with broad rights sitting in a config file.
Assume a mistake will happen, and catch it
Discipline is necessary but not sufficient, because people make mistakes under deadline. So the prohibition is backed by automation that does not get tired: secret scanning runs in continuous integration and blocks a merge that would introduce a credential, before it ever reaches the shared history. The goal is not to trust that no one will ever paste a key; it is to make sure that if someone does, it is caught at the door.
- Secrets stored in a managed vault, never in the repository or its history.
- Short-lived, least-privilege identities instead of standing, broadly scoped keys.
- Secret scanning in CI, so an accidental credential fails the build rather than shipping.
- Rotation as a routine operation, so any credential's useful lifetime is bounded by design.
Deleting a secret from the latest commit does not delete it from history. By then, the only safe move is to rotate it.
What this buys the institution
Keeping secrets out of the codebase makes the repository safe to share with reviewers, auditors, and new engineers without handing anyone the keys to production. A leaked clone becomes a leak of code, not of access. And because credentials are short-lived and centrally managed, revoking or rotating them is a controlled operation rather than a frantic search through files no one fully remembers writing.