Serguey Asael Shinder – IT Professional

I found it by accident, scrolling back through the history of a project to understand how something had evolved. There, in a commit from years earlier, sat an API key — pasted directly into the code, and then removed in the very next commit. Whoever did it had clearly realized the mistake within minutes. It didn’t matter. The key was still there, preserved forever in the history, one clone away from anyone.

That moment rearranged how I think about secrets. I had always vaguely known you shouldn’t hard-code them, but I’d treated it as a style rule. Standing there looking at a live-looking credential frozen in the past, it stopped being style and became something visceral. The repository remembers everything. Deleting a line doesn’t delete its history. Git is, by design, an archive that forgives nothing.

The second thing it taught me was subtler and more important. The instinct when you find a leaked secret is to hide the evidence — quietly remove the line, hope nobody noticed. That instinct is exactly wrong. The moment a secret lands in a commit, it’s burned. Not “at risk.” Burned. The only real response is to rotate it, to make the exposed key worthless, not to tidy up the scene of the exposure.

So I changed how I work. Secrets live outside the code now — in the environment, in a proper secret manager, anywhere but the source that gets cloned and copied and pushed to places I can’t see. And I made rotation cheap, a thing I can do in a minute, because a leak you can’t respond to quickly is a leak that stays dangerous.

None of this is exciting. That’s the point. The exciting security stories are the ones you spend a career trying never to star in. The boring discipline — config outside the code, keys you can rotate without ceremony — is what keeps you out of them. I learned it from a stranger’s mistake, sitting quietly in an old commit, waiting.

– Serguey Asael Shinder