In software, there are many kinds of secrets: API keys, encryption keys, passwords and so on. Anyone who has one of these values is allowed to do something. This applies both to systems that can have their own keys and to people who receive a key.
Every application we build needs a few. So we have agreed how to create them, who can access them, when to replace them and what to do if something goes wrong.
As few as possible, of everything. Our first principle is minimisation: as few secrets as possible, as few people with access as possible and as few places where they exist as possible. Every extra secret is something to store, track and eventually replace. We avoid sharing them where we can.
We never create new secrets by hand. They are generated: long, random and with strength appropriate to their type. A password you invent yourself may feel creative, but statistically it rarely is. That is why using a password manager is mandatory for us.
We keep a central register of our secrets. For each secret it records:
- its name and purpose;
- which system uses it;
- who owns it and who can access it;
- when it was created and last replaced;
- when it must be replaced again.
If a value has to move from one colleague to another, it goes through a secure channel, never our regular chat tool. The rules in the employee handbook apply too: lock your screen when you walk away.
Replacing secrets. Replacing a secret is called rotation, and we do it at fixed times rather than only when something goes wrong. The schedule differs by type. We also rotate a secret when someone leaves the company, after a suspected or confirmed leak, and after a major change to a system.
That last case deserves an explanation. Break-glass access is an emergency entrance: a way to get in when the normal route does not work, with the agreement that it is used only in exceptional situations. Such an entrance is trustworthy only if you know it works, so we test it periodically. After it is used, the associated secret is always replaced, so the emergency entrance does not quietly become a second front door.
If something leaks. If you suspect a secret has leaked, report it to our Security Officer immediately. And do not start working on it yourself. During security incidents, we wait for the investigation because hurried action can erase traces needed to understand what happened. Restarting a system, for example, can unintentionally remove log files or appear to solve the problem. A solution is useful only if you understand exactly what went wrong in the first place.
After that, the order is: limit the impact, revoke and replace the value, check that everything is running again, find out what went wrong and update the register. That last step may look like administration, but without it the overview is no longer accurate after an incident.
Keep improving. After a rotation or a leaked secret, we ask why it happened and how to strengthen our approach, for example with a shorter replacement interval or an extra check of code and logs. Such an improvement gets an owner, as described in continual improvement.