I agree, this seems like straight up bad design from a security perspective.

But at the same time, me as a customer of Github, would prefer if Github made it harder for vendors like CodeRabbit to make misstakes like this.

If you have an app with access to more than 1M repos, it would make sense for Github to require a short lived token to access a given repository and only allow the "master" private key to update the app info or whatever.

And/or maybe design mechanisms that only allow minting of these tokens for the repo whenever a certain action is run (i.e not arbitrarily).

But at the end of the day, yes, it's impossible for Github to both allow users to grant full access to whatever app and at the same time ensure stuff like this doesn't happen.

The private key isn’t a key in the “API KEY” sense, it’s a key in the “public/private key pair” sense. It’s not sent to github and there’s no way for them to know if the signing of the token used to make the call happened in a secure manner or not, because github doesn’t receive the key as part of the request at all.

GH Apps already use short-lived tokens that can be scoped per repo. You mint a token using your private key and exchange it for a token via API. Then you use that token and dispose of it. That's the only way to use GH Apps (User Access Tokens which are the same thing, but require user interaction) Those tokens always expire.

I'd rather GitHub finally fix their registry to allow these GH Apps to push/pull with that instead of PAT.

That's...literally the way it already works.

There is a master private key that mints expiring limited-use tokens.

The problem was leaking the master private key.