Feature: Clarify why zizmor itself needs `actions: read` permission

[johnbillion]

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 both the open and closed issues for a duplicate request.

What's the problem this feature will solve?

I'm auditing the permissions in my workflow files and I haven't been able to identify why the actions: read permission is required by the GH_TOKEN that zizmor itself uses for its checks when it runs on GitHub Actions.

I looked at the list of audit rules that don't work offline to see if I could figure out which one requires it, but with no luck.

Candidates:

• impostor-commit
• known-vulnerable-actions
• ref-confusion
• stale-action-refs

Previous issue: #608

Describe the solution you'd like

Could you confirm why this permission is required by zizmor and which audit rule uses it?

Additional context

Big fan of zizmor!

[woodruffw]

Hey @johnbillion, thanks for opening an issue (and for the kind words!)

Yeah, this is a source of confusion: zizmor itself doesn't need actions: read, but the integrations that zizmor-action uses by default (namely SARIF uploads) needs it (or at least, GitHub's own docs claim that it's needed).

For reference, here's GitHub's own docs on SARIF uploads:

https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github

The actual permissions needed by zizmor itself are documented here: https://docs.zizmor.sh/usage/#github-api-token-permissions

TL;DR: None of the audits need that permission, and if you're not using the SARIF integration (which is enabled by default) you can remove it. It's documented by default because most people use it (at least I think they do 😅), but I'm open to suggestions on how to more clearly document/distinguish between permissions zizmor needs and permissions that zizmor-action needs for various integration points.