If rogue party has access to the key, they can do a lot more damage.

Indeed, so you’re building all this tooling and complexity and introducing more issues for the very small intersection of people that:

1. Are not malicious

2. Have access to a key

3. Are unable or unwilling to commit it to GitHub

It would be great if this stuff was public and available without a central authority. But after working on it for a while it seems like a fairly good compromise.

There’s already an entire pipeline that handles a key being compromised when it is found on GitHub. All the “tooling and complexity” you need is a simple HTML form to ask for a key and where you found it, and some server-side code to trigger the same pipeline when somebody submits the form.

There are three issues with the use of GitHub here:

1. Not everybody knows that AWS will invalidate tokens committed into a public GitHub repository.

2. There is a window (67 seconds according to OP) in which the compromised token is public but working. For the “small intersection of people”, you could bring it down to 0.

3. GitHub protects GitHub keys, and apparently AWS keys, but does it protect Azure keys? Or GCP keys?

GitHub secret scanning is a product they allow partners to take advantage of: https://docs.github.com/en/code-security/secret-scanning/abo...

Not necessarily people but systems. Your code hosting platform, your mailing-list host, your chat app, ... are all examples of systems who are hopefully not malicious and could easily add this auto-revoke-publicly-leaked-secret feature, if it was a simple consistent scheme like an HTTP DELETE to a URL.