self-hosted-runner: detect Github large runners

[ubiratansoares]

Pre-submission checks

• I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
• I have looked through the open issues for a duplicate request.

What's the problem this improvement will solve?

Right now, the self-hosted audit assumes that having runs-on along with a defined Runners group implies self-hosted Runners. However, Github large runners are also defined on top of Runner Groups, meaning that we may be flagging as self-hosted a Runner actually hosted by Github

Describe the solution you'd like

There are a couple of endpoints in the Github REST API related to runner groups, including listing self-hosted runner groups, and listing runners that belong to that group.

Perhaps we can query the Github API and match against the value defined in the Workflow. This solution requires a Github PAT with org:admin permission, though 💔

Additional context

No response

[woodruffw]

Thanks @ubiratansoares! We should definitely improve our handling here, but that level of permission in the API token is probably a dealbreaker 😞 -- we could tell users how to configure a stronger token here, but I'm concerned that documenting that will lead to people giving zizmor way overscoped tokens when then represent their own security issue.

Any thoughts on how we could overcome this, or maybe sidestep it with a heuristic?

[ubiratansoares]

Yeah ... The overscoping is an issue indeed 😭

I don't have any ideas on how to overcome this without the REST API. My first suggestion is flagging that group may imply self-hosting in the audit message, since the audit confidence is already set to low in this case.