When your own secret scanner is right and "it's just a placeholder" is the wrong answer

Symptom. A routine commit, mid-restructure, gets blocked — a commit-time secret scanner flags what looks like a private key inside a Kubernetes manifest.

Investigation. The key material was real, but genuinely low-stakes: a self-signed cert, trusted by nobody, that the gateway used only as something to boot with before the real dev-TLS tooling took over. The file's own header comment said it had been committed on purpose, for exactly that reason. Every reasonable-sounding argument pointed toward "override the block, this one is fine" — which is exactly the moment to stop and ask instead of just doing it. Laid out three honest options: confirm it is fine and commit anyway, strip it out and redesign, or stop and look closer.

Root cause and fix. The real question was never "is this specific key dangerous." It was "does this key need to live in git at all." It did not. Redesigned it as an init container that generates a brand-new self-signed cert into an ephemeral volume every time the pod boots. Same behaviour — the gateway always has something to start with — and zero key material checked into source control, ever.

Lesson. A secret scanner blocking a "harmless" placeholder is not a false positive to wave through. It is a design smell. If something only needs to exist at runtime, generate it at runtime; do not check it in "just this once," even when the file itself insists that is fine.