Rule 9 of 12 · Chapter III — Running Keys in the Open
Keep key material out of source code, configuration files, container images, and firmware builds.
Why this rule exists
If the key lives in an artefact, the key inherits that artefact's entire distribution history — every clone, every registry mirror, every backup, every laptop that ever built it. Kerckhoffs's bargain only works if the single secret is genuinely narrower than the system; a hardcoded key makes the secret exactly as wide as the code. Worse, embedded keys are hard to rotate: you cannot revoke a firmware image that is already in a customer's hands.
In practice
Load keys at runtime from a secrets manager, a hardware module, a sealed TPM, or an operator-supplied injection step, and let the artefact contain only the reference to them. Scan commits and built images for high-entropy strings and known key formats before they ship, and treat any hit as a real incident with rotation, not a lint warning. Keep development and test keys obviously fake and clearly labelled so nobody promotes one by accident.
When it doesn't apply
Public keys, trust anchors, and pinned certificates belong in the build — that is the point of them. A device with no secure element and no provisioning channel may have to carry a unique per-unit key burned at manufacture; that is a hardware constraint, not a licence to ship the same key to every unit.