Potential fixes for 2 code scanning alerts

[cinderellasecure]

https://github.com/github/prodsec-engineering/issues/748

Potential fixes for 2 code scanning alerts from the Copilot AutoFix: Missing Permissions in Workflows security campaign:

• https://github.com/github/turbo/security/code-scanning/12
  To fix the issue, we should explicitly add a permissions block to the job (or the workflow root) in .github/workflows/ci.yml, limiting GITHUB_TOKEN access to the minimal permissions required. Since none of the job steps seem to require write access, the minimal permissions: contents: read is sufficient. This block can be placed either at the workflow root (to apply to all jobs) or directly under the build job (to apply just to this job). Since only one job is present, either location is suitable, but typically setting it at the job-level is preferred for clarity. The block should be added above the steps: section for the build job.

  ---

• https://github.com/github/turbo/security/code-scanning/11
  To fix the problem, add an explicit permissions block to the workflow YAML. The minimal safe starting point is to set contents: read, which allows the default steps that only need read, while ensuring that no unnecessary write permissions are granted.

  • In this workflow, it's most appropriate to add the permissions: block at the root level, just below the name: and above on: so the least privilege applies to all jobs unless overridden locally.
  • This only changes the access level of the auto-generated GITHUB_TOKEN and does not affect secrets or other tokens.
  • No other code needs to be changed: just one block added to set explicit permissions.

  ---

Suggested fixes powered by Copilot Autofix. Review carefully before merging.

[Copilot]

Pull Request Overview

This PR adds permissions configurations to GitHub Actions workflows to follow the principle of least privilege. The changes restrict workflow permissions to only what is necessary for each workflow to function.

• Added contents: read permission at the workflow level in publish-beta.yml
• Added contents: read permission at the job level in ci.yml

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
.github/workflows/publish-beta.yml	Added workflow-level contents: read permission
.github/workflows/ci.yml	Added job-level contents: read permission

Comments suppressed due to low confidence (1)

.github/workflows/publish-beta.yml:35

• The publish-beta.yml workflow publishes packages to npm (lines 32-40), which requires write permissions. However, the workflow-level contents: read permission restricts all other permissions to 'none' by default, including the id-token and packages scopes. While npm publishing uses NODE_AUTH_TOKEN for authentication (not GitHub token permissions), consider explicitly documenting why only contents: read is needed, or verify that npm publishing works correctly with this restricted permission set.

      - run: npm publish --tag next
        if: github.ref == 'refs/heads/main'
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] In publish-beta.yml, permissions are set at the workflow level (lines 2-3), while in ci.yml, permissions are set at the job level (lines 8-9). For consistency and maintainability, consider using the same permission scope pattern across all workflows. Job-level permissions are generally preferred as they provide more granular control if multiple jobs are added later.

[jibrang]

Do you think we'll need write permissions as well since this step is to publish a package?