ci: Add minimum GitHub token permissions for workflows

[varunsh-coder]

Description

This PR adds minimum token permissions for the GITHUB_TOKEN in GitHub Actions workflows using https://github.com/step-security/secure-workflows.
All GitHub Actions workflows have a GITHUB_TOKEN with write access to multiple scopes.
Here is an example of the permissions in one of the workflows:
https://github.com/zulip/zulip/runs/8006109927?check_suite_focus=true#step:1:19

After this change, the scopes will be reduced to the minimum needed for the workflows.

Motivation

• This is a security best practice, so if the GITHUB_TOKEN is compromised due to a vulnerability or compromised Action, the damage will be reduced.
• GitHub recommends defining minimum GITHUB_TOKEN permissions.
  https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token
• The Open Source Security Foundation (OpenSSF) Scorecards also treats not setting token permissions as a high-risk issue. This change will help increase the Scorecard score for this repository.

Signed-off-by: Varun Sharma varunsh@stepsecurity.io

Self-review checklist

• Self-reviewed the changes for clarity and maintainability
  (variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

• Explains differences from previous plans (e.g., issue description).
• Highlights technical choices and bugs encountered.
• Calls out remaining decisions and concerns.
• Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

• Each commit is a coherent idea.
• Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

• Visual appearance of the changes.
• Responsiveness and internationalization.
• Strings and tooltips.
• End-to-end functionality of buttons, interactions and flows.
• Corner cases, error conditions, and easily imagined bugs.

[PIG208]

@varunsh-coder thank you for submitting the PR! Could you squash these two commits and removed the commit message in the second one?

[varunsh-coder]

@varunsh-coder thank you for submitting the PR! Could you squash these two commits and removed the commit message in the second one?

Done!

[timabbott]

Thanks for the explanation and pull request @varunsh-coder! This is clearly an improvement, but I'm curious whether it'd be better to just set the default token permissions to "restrictive" for the repository, as documented here, rather than doing overrides to reduce permissions in individual workflows:

https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

It seems like that would protect us better if future workflows are added. (I think we'd still need the "security events" hunk as that's an increase in permissions?)

[timabbott]

The Open Source Security Foundation (OpenSSF) Scorecards also treats not setting token permissions as a high-risk issue. This change will help increase the Scorecard score for this repository.

Is there a way to run this scorecard without installing their GitHub Action?

[varunsh-coder]

Thanks for the explanation and pull request @varunsh-coder! This is clearly an improvement, but I'm curious whether it'd be better to just set the default token permissions to "restrictive" for the repository, as documented here, rather than doing overrides to reduce permissions in individual workflows:

https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

It seems like that would protect us better if future workflows are added. (I think we'd still need the "security events" hunk as that's an increase in permissions?)

Hi @timabbott, you can also set the default token permissions to "restrictive" for the repository, and yes that will help with future workflows as well.

Setting in the workflow file has couple of advantages:

1. Tools like Scorecards cannot access the setting in the repository (there is no API for it), so assume that the workflows have not set minimum permissions.
2. If someone forks the repo, or ends up re-using the workflow in a different repo, the permissions go along if present in the workflow file. The repo settings are not copied over when forked.

Yes, the security-events: write will need to be set explicitly.

Please let me know whatever you decide and if you want me to update the PR. Thanks!

[varunsh-coder]

The Open Source Security Foundation (OpenSSF) Scorecards also treats not setting token permissions as a high-risk issue. This change will help increase the Scorecard score for this repository.

Is there a way to run this scorecard without installing their GitHub Action?

Yes, you can run it using the CLI. https://github.com/ossf/scorecard#installation

For some repositories (what publish a package), the scores are also available at https://deps.dev

[timabbott]

Merged, thanks for the contribution and information @varunsh-coder!

[timabbott]

Also posted https://chat.zulip.org/#narrow/stream/43-automated-testing/topic/GitHub.20token.20permissions/near/1427444; we'll want to do something similar for our other major repositories like zulip/zulip-mobile.