Deep-Dive Enumaration

[AdnaneKhan]

There are lots of checks that could be performed on a repository that involve additional API queries, and we probably only want to run them after we've identified a repository of interest:

• Enumerate all accessible self-hosted runners by downloading more run logs.
• Enumerating check runs triggered by PRs
• Testing if previous contributors can run pull_request workflows without approval.

Essentially, learn as much as possible via what is publicly accessible. This could be a flag that only works with single repository enumeration.

[AdnaneKhan]

This relates to #51, but it could be something like the following enumeration profiles:

--zoomies: Skip run logs, skip branch protection rules. YML-based enumeration only for the entire search set (currently, the dev branch only does this when there are > repos for org enum). This would be the profile to use for secrets + assessing access of a PAT, and not for SH runners. --fast: Download last 10 run logs, but only if workflow ymls suggest a SH runner. Secrets if the token has write access. Don't query branch protections, etc. unless the token as write access. Yml-based enum for public repos only. Short-circuit after first SH runner identified via run logs. --standard: Last 30 run logs, but only look at 1 per workflow.yml + event pairing. So this usually shakes out to 5-10 per repo. Short-circuit after first SH runner identified via run logs. Deployment envs checked only if write or above access (for secrets). --thorough: Download up to 100 run logs per repo (2 per workflow.yml + event pairing). Analyze all, not just those ID'd via static check. Don't short circuit - this allows capturing a set of runners per repo. Also, enumerate branch protections and deployment environments. --comprehensive: Download up to 100 run logs per repo (up to 5 per workflow.yml + event pairing) Analyze branch protections, environments, 3rd party checks (such as Azure pipelines, etc.) and check fork PR approval requirements via heuristics.