ci: declare minimum permissions on stale-issues workflow

[arpitjain099]

Pins .github/workflows/stale-issues.yml to the minimum scopes actions/stale@v10 actually uses: issues: write and pull-requests: write. The workflow runs two passes of actions/stale, one for the default 365-day timeline and one for needs-information issues on a 30-day accelerated path. Both passes only touch labels, comments, and close-state on issues and PRs - neither needs contents access at all.

CVE-2025-30066 (the March 2025 tj-actions/changed-files supply-chain attack) is the motivation: a tampered third-party action exfiltrated GITHUB_TOKEN from workflow logs and the blast radius equalled whatever scope was issued. Today this workflow inherits the org-default token scope, so if that default is anything broader than issues+pull-requests: write the daily cron is silently handing more authority to actions/stale than the action needs. Pinning at the actual minimum closes that gap, gives drift protection, and registers with OpenSSF Scorecard's Token-Permissions check.

YAML validated locally with yaml.safe_load.

---

Note

Low Risk
Low risk configuration change, but could affect the scheduled stale automation if the declared token permissions are insufficient or too restrictive.

Overview
Adds an explicit permissions block to .github/workflows/stale-issues.yml to scope the GITHUB_TOKEN for actions/stale@v10 runs (issues/PR write, plus actions write) instead of relying on repository/org defaults.

This reduces the workflow’s token blast radius for the scheduled stale issue/PR labeling and closing automation without changing the stale policy logic itself.

^{Reviewed by Cursor Bugbot for commit 3703d24. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

Hi, I’m Jit, a friendly security platform designed to help developers build secure applications from day zero with an MVS (Minimal viable security) mindset.

In case there are security findings, they will be communicated to you as a comment inside the PR.

Hope you’ll enjoy using Jit.

Questions? Comments? Want to learn more? Get in touch with us.

[petyaslavova]

Hey @arpitjain099, thank you for your contribution! Can you please apply the suggested change and it will be ready for merging :)

[arpitjain099]

Thanks @petyaslavova, applied. Added actions: write to the permissions block per the Bugbot suggestion. The reasoning makes sense: actions/stale@v10 reaches into the Actions cache for state tracking once operations-per-run is hit, and without the scope it would 403 on cache writes and silently skip issues across runs.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 3703d24. Configure here.}

[cursor]

Overly broad actions: write undermines minimum-permission goal

Medium Severity

The actions: write permission grants the ability to cancel, re-run, and delete workflow runs — not just manage caches. This contradicts the PR's explicit goal of minimizing blast radius against supply-chain attacks (CVE-2025-30066). A compromised actions/stale with this scope could disrupt CI/CD by canceling runs or destroy audit trails by deleting them. This is a known concern tracked in actions/stale#1159. The PR description itself states the minimum scopes are only issues: write and pull-requests: write.

 

^{Reviewed by Cursor Bugbot for commit 3703d24. Configure here.}