[New Check]: Ensure organizations grant workflows a read-only default GITHUB_TOKEN

[Edneam]

Existing check search

• I have searched existing issues, Prowler Hub, and the public roadmap, and this check does not already exist.

Provider

GitHub

New provider name

No response

Service or product area

organization

Suggested check name

organization_default_workflow_permissions_read_only

Context and goal

• Security condition to validate: The organization default GITHUB_TOKEN permissions granted to GitHub Actions workflows are read-only, so a workflow has to opt in to write access with an explicit permissions block.
• Why it matters: When the organization default is read-write, every workflow run in every repository starts with a token that can push commits, move tags, and edit releases. Any compromised step or dependency in any of those workflows inherits that token, which turns a single malicious action into a code integrity problem across the organization. Setting the default to read-only makes write access an explicit, reviewable decision per workflow.
• Resource, feature, or configuration involved: Organization Settings > Actions > General > Workflow permissions, exposed as default_workflow_permissions on GET /orgs/{org}/actions/permissions/workflow.

This is an organization-level setting rather than something written in a workflow file, so it is not visible to the existing githubactions_workflow_security_scan check, which reports workflow file findings from zizmor. I searched the github provider for default_workflow_permissions, workflow_permissions, and GITHUB_TOKEN and found no coverage.

Expected behavior

• Resource or scope to evaluate: Each organization in scope.
• PASS when: default_workflow_permissions is read.
• FAIL when: default_workflow_permissions is write.
• Exclusions, thresholds, or edge cases: Personal accounts have no such setting, and a token without organization administration access cannot read it. In both cases the setting is unknown, so no finding should be reported for that organization rather than guessing a status.

References

• Product documentation: https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization
• API reference: https://docs.github.com/en/rest/actions/permissions (Get default workflow permissions for an organization)
• Hardening guidance: https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication
• Sample response: {"default_workflow_permissions": "read", "can_approve_pull_request_reviews": false}

Suggested severity

High

Additional implementation notes

• Required permissions or scopes: the organization Actions permissions endpoints need admin:org for classic personal access tokens, or organization administration read for fine-grained tokens. Without it the endpoint returns 403 and the setting stays unknown.
• Other constraints: the same endpoint also returns can_approve_pull_request_reviews, which is a separate control and would fit better as its own check rather than being folded into this one.

I would like to work on this one, and I already have an implementation ready to open as a PR: the field is read in organization_service.py through the same raw request pattern used for repository rulesets, with unit tests covering read, write, unknown, 404, and 403.