Skip to content

ci: declare workflow-level contents: read on ci + nightlies workflows#6051

Open
arpitjain099 wants to merge 1 commit into
cockroachdb:masterfrom
arpitjain099:chore/declare-workflow-perms-readonly
Open

ci: declare workflow-level contents: read on ci + nightlies workflows#6051
arpitjain099 wants to merge 1 commit into
cockroachdb:masterfrom
arpitjain099:chore/declare-workflow-perms-readonly

Conversation

@arpitjain099

Copy link
Copy Markdown
Contributor

Pins the default GITHUB_TOKEN to contents: read on the 6 workflows in .github/workflows/ that don't actually need any write scope:

  • ci.yaml: PR/push CI suite.
  • nightlies.yaml: master nightlies entry point.
  • nightlies-25.2.yaml, nightlies-25.4.yaml, nightlies-26.1.yaml, nightlies-26.2.yaml: per-release nightly stress runs.

None call a GitHub API beyond the initial checkout, so contents: read is sufficient.

Left implicit on purpose:

  • code-cover-gen.yaml uses gh pr view (needs pull-requests: read).
  • nightly-code-cover.yaml passes github.token to a gh-cli step.
  • code-cover-publish.yaml writes coverage results.

Those three are best declared by a maintainer who knows whether to put the extra scope at workflow or job level.

Why

CVE-2025-30066 (March 2025 tj-actions/changed-files supply-chain compromise) exfiltrated GITHUB_TOKEN from workflow logs. Pinning per workflow caps runtime authority irrespective of the repo or org default, gives drift protection if the default ever widens, and is credited per-file by the OpenSSF Scorecard Token-Permissions check.

YAML validated locally with yaml.safe_load on each touched file.

@arpitjain099 arpitjain099 requested a review from a team as a code owner May 14, 2026 22:42
@arpitjain099 arpitjain099 requested a review from xxmplus May 14, 2026 22:42
@cockroach-teamcity

Copy link
Copy Markdown
Member

This change is Reviewable

@arpitjain099

Copy link
Copy Markdown
Contributor Author

@RaduBerinde - approved + green; any window to land this when convenient? Happy to rebase if it's drifted.

Pins the default GITHUB_TOKEN to contents: read on the 6 workflows in
.github/workflows/ that don't actually need any write scope:

- ci.yaml: PR/push CI suite.
- nightlies.yaml: master nightlies entry point.
- nightlies-25.2.yaml, nightlies-25.4.yaml, nightlies-26.1.yaml,
  nightlies-26.2.yaml: per-release nightly stress runs.

None call a GitHub API beyond the initial checkout.

Left implicit on purpose:

- code-cover-gen.yaml uses 'gh pr view' (needs pull-requests: read).
- nightly-code-cover.yaml passes github.token to a gh-cli step.
- code-cover-publish.yaml writes coverage results.

Those three are best declared by a maintainer who knows whether
pull-requests: read at workflow or job scope is the right shape.

Motivation: CVE-2025-30066 (March 2025 tj-actions/changed-files
compromise) exfiltrated GITHUB_TOKEN from workflow logs. Per-workflow
caps bound runtime authority irrespective of repo or org default,
give drift protection if the default ever widens, and are credited
per-file by the OpenSSF Scorecard Token-Permissions check.

YAML validated locally with yaml.safe_load.

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
@arpitjain099 arpitjain099 force-pushed the chore/declare-workflow-perms-readonly branch from b4731b7 to 90301d9 Compare June 10, 2026 07:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants