Comment by thewisenerd 6 days ago
even if they did not have the PEM file left in the environment, the token is still widely scoped and has the same scope as the PEM
what i'm clearly mis-remembering is being able to exchange the token for a smaller scope e.g., hey~ sign this jwt, with scopes=[org/repo1, org/repo2, permissions=write]
ah; understood. assuming PEM leakage aside
the scope of the exchanged token is the scope of the installation (org / repo); thereby limiting exposure already
to further reduce the scope of exposure, the jwt would've needed to be exchanged with the specific `repositories` (given most installations are org scoped) and `permissions`
https://docs.github.com/en/apps/creating-github-apps/authent...
> the token is still widely scoped and has the same scope as the PEM
What the person above you is trying to tell is you is that no, it doesn't.
The authentication flow is that the private key is used to sign an initial JWT; that gets you access to some GH API calls. From there you exchange that JWT for an access token with smaller scope, scoped only to the installation in question.
While the tool execution environment ought to have had none of the credentials, there is the possibility of only holding onto the installation access token.