ci: declare contents:read on code-quality workflow#1026
Conversation
Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
|
|
|
|
Merging mentally with #1040 which covers this plus more files. Closing this PR. |
Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
|
|
|
|
Merging mentally with #1040 which covers this plus more files. Closing this PR. |
Adds a workflow-level
permissions: contents: read. The job checks out the repo and runs the linter / format checker; nothing here calls a GitHub API beyond the initial checkout, and the action surfaces failures as the workflow's own check status.This is supply-chain hygiene anchored in CVE-2025-30066 - the March 2025
tj-actions/changed-filescompromise - where a tampered third-party action readGITHUB_TOKENout of workflow logs and the blast radius equalled whatever scope was issued. Pinning per workflow caps that runtime authority irrespective of the repo or org default, gives drift protection if the default ever widens, and is what OpenSSF Scorecard's Token-Permissions check credits. Small files like this one are the easy place to start the org-wide hygiene work.YAML validated locally with
yaml.safe_load.Note
Low Risk
Narrowing workflow token scope only; no application or auth logic changes.
Overview
Adds workflow-level
permissions: contents: readto the Code quality checks workflow in.github/workflows/code-quality.yml, so the job’sGITHUB_TOKENis limited to what checkout and local lint/typecheck steps need instead of inheriting broader repo/org defaults.This is supply-chain / least-privilege hygiene (aligned with OpenSSF Scorecard token-permissions expectations); behavior of the job steps is unchanged.
Reviewed by Cursor Bugbot for commit a7e82f6. Bugbot is set up for automated code reviews on this repo. Configure here.