in 2019 i saw a fortune500 tech company put in place their own vulnerability scanner internal application which included this feature for our enterprise github repos. the tool was built and deployed to an old Linux docker image that was never updated to not be the target of the attack they were preventing... they never vetted to random version they started with either. i guess one can still use zip bomb or even the xz backdoor for extra irony points when attacking that system.
anyway, the people signing github checks also get promoted by pretending to implement that feature internally.
For their fix, they disabled debug logs...but didn't answer if they changed the temp tokens permissions to something more appropriate for a code analysis engine.
Historically the only choice was permissive by default, so this is unfortunately the setting used by older organizations and repos.
When a new repo is created, the default is inherited from the parent organization, so this insecure default tends to stick around if nobody bothers to change it. (There is no user-wide setting, so new repos owned by a user will use the restricted default. I believe newly created orgs use the better default.)
[0]: https://docs.github.com/en/actions/security-for-github-actio...
> Read and write permissions
> Workflows have read and write permissions in the repository for all scopes.
> If the default permissions for the GITHUB_TOKEN are restrictive, you may have to elevate the permissions to allow some actions and commands to run successfully.
For their quick fix, hopefully not for their final fix.
1: https://docs.github.com/en/actions/security-for-github-actio...
fun claims: https://github.com/github/actions-oidc-debugger#readme
Edit: Success is not the absence of vulnerability, but introduction, detection, and response trends.
(Github enterprise comes out of my budget and I am responsible for appsec training and code IR, thoughts and opinions always my own)
[1] _and failing_.
Luckily it was quickly remedied at least.