The most repeated mistake
Almost every security incident with an internal origin starts the same way: an access key, a token or a password somebody left in a configuration file 'just for testing'. The repository was private, so it looked safe. But a repository gets cloned, shared, pushed elsewhere and keeps its history forever. Deleting the file does not delete the secret: it is still in the history.
Separating the name from the value
The rule is simple and has no exceptions:
- In the repository (and in the registry) you write down which secrets each application needs, by name: 'the orders application needs its database password'.
- In a secret manager the value is kept, encrypted, with control over who can read it.
- At deployment, the platform looks up each value by its name and hands it to the running application. The value never touches the repository or the logs.
What comes with that separation
- Rotating is easy: you change the value in the manager and redeploy. The code does not change.
- You know who accesses it: the manager logs every read.
- Each environment has its own values under the same name, so the code is identical in development and in production.
- What does not exist cannot leak: if somebody shares the repository, they share names, not keys.
And an automatic check
However clear the rule is, somebody will break it one day by accident. That is why the platform reviews every change looking for things shaped like a secret (keys, tokens, passwords) and rejects it before it is stored. A timely rejection is cheaper than an emergency rotation.
With the registry and the secrets solved, the third source of truth is missing: the one that tells what has happened to each application.
How we apply it: Platform Engineering.