Every security leader has lived some version of this incident. A researcher, a scanner, or a well-meaning stranger finds one of your API keys sitting in a public repository. Now the clock is running, but instead of a kill switch, what follows is a scavenger hunt. Which company issued this key? Who do I contact? Is there a security.txt? Does anyone read that inbox? By the time the right person revokes the right credential, hours or days have passed, and attackers needed minutes. Bots scrape public repos constantly, and the majority of leaked secrets are still active years later.
Here’s what strikes me about this problem: we already solved it once. In 2013, OAuth got RFC 7009, a standardized token revocation endpoint discoverable through a well-known configuration URL. Any conformant client can kill a token programmatically. Then the industry kept right on shipping plain API keys, the credential type that actually leaks the most, with no revocation story at all.
The one bright spot is GitHub’s Secret Scanning Partner Program: providers register key patterns, GitHub scans public commits, revocation happens by webhook. It works, and it’s proprietary, centralized, and invite-only. Meanwhile, look at where the open-source scanning world is heading. The new generation of scanners all list the same roadmap item: automatic revocation via provider APIs. Every one of them will have to hand-build integrations, provider by provider, because there is no standard way to ask an issuer “please kill this key.”
