arpitjain099 commented on PR #40069: URL: https://github.com/apache/superset/pull/40069#issuecomment-4452782027
Hey @sadpandajoe, fair question. The concrete impact: **What changes** For these three workflows, the implicit `GITHUB_TOKEN` is currently scoped by the repo default (on most Apache repos that means contents-write available at the workflow level, and the default can be widened via a settings change you might not notice). This PR pins each one to the minimum scope it actually needs: - `release.yml`: `contents: read` - `superset-docs-deploy.yml` / `superset-docs-verify.yml`: `contents: read` plus `actions: read` (they download artifacts from prior workflow runs) Nothing in the diff changes what the workflows *do*; only the scope of the token they receive when running. **Why it matters (threat model)** The `GITHUB_TOKEN`'s scope is the blast radius when a third-party action is compromised. The canonical recent case is CVE-2025-30066 (`tj-actions/changed-files`), where a popular action was backdoored and exfiltrated/abused whatever the calling workflow's token could touch. Repos with default-scope tokens handed attackers push access. Repos that had already pinned `permissions:` blocks gave them nothing useful. This PR doesn't claim Superset is currently broken. It removes a class of latent damage: if any action used by these three workflows is ever supply-chained, the token can only read. **Why each scope is what it is** - `release.yml`: build/sign steps already use repo secrets directly; the token itself only needs to read the source. - `superset-docs-deploy.yml` / `superset-docs-verify.yml`: download artifacts from earlier runs (`actions: read`) and run Netlify deploy with its own token. No GitHub API write. **Why bother now** - Brings these three in line with the rest of `.github/workflows/`, where the other files already declare `permissions:` blocks. These were the leftover holdouts. - Lets the OpenSSF Scorecard `Token-Permissions` check pass on these files (it's per-file; the implicit-scope holdouts drag the overall score down). - Pure no-op at runtime, so the risk of merging is essentially zero. If the project's preference is the other direction (broad default, no per-file pinning) I'm happy to close. Otherwise this should be a safe merge. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
