ci: declare permissions on the four project-automation workflows#8978
ci: declare permissions on the four project-automation workflows#8978arpitjain099 wants to merge 1 commit into
Conversation
The three project_automation_* workflows authenticate every step via
tibdex/github-app-token using CCCL_AUTH_APP_ID + CCCL_AUTH_APP_PEM,
so the workflow's implicit GITHUB_TOKEN is unused. `permissions: {}`
captures that contract.
triage_rotation.yml is the exception: it uses github.token directly
through `gh issue edit --add-label`, `gh issue comment`, and a
GraphQL addAssigneesToAssignable mutation. Per-job `issues: write`
is the minimum that covers all three calls.
All four trigger on pull_request_target / issues, the elevated-context
shape, so pinning the workflow scope is high-signal: the implicit
default-branch GITHUB_TOKEN no longer has anything to grant the
project_automation workflows, and triage_rotation is scoped to just
the API calls it actually makes.
Style matches the per-job and workflow-level permissions blocks
already used in backport-prs.yml, bench.yml, blackduck-sca.yml, and
the other hardened workflows.
Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
📝 WalkthroughSummary by CodeRabbit
WalkthroughFour GitHub Actions workflows are updated to explicitly configure token permissions: three restrict default GITHUB_TOKEN permissions to empty (they use GitHub App token instead), and one enables explicit ChangesGitHub Actions Workflow Permission Hardening
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 841ae019-28b7-449c-abff-4cded9c7a03a
📒 Files selected for processing (4)
.github/workflows/project_automation_set_in_review.yml.github/workflows/project_automation_set_roadmap.yml.github/workflows/project_automation_sync_pr_issues.yml.github/workflows/triage_rotation.yml
| # Workflow token unused: every step authenticates via tibdex/github-app-token. | ||
| permissions: {} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Find workflow actions not pinned to a full 40-char commit SHA.
# Expected: this flags mutable refs like tibdex/github-app-token@v1.8.0.
rg -nP '^\s*uses:\s*(?!\./)(?!docker://)[^@\s]+@(?![0-9a-fA-F]{40}\b)[^\s#]+' .github/workflows/*.ymlRepository: NVIDIA/cccl
Length of output: 4719
🏁 Script executed:
cat .github/workflows/project_automation_sync_pr_issues.ymlRepository: NVIDIA/cccl
Length of output: 9447
important: pin tibdex/github-app-token@v1.8.0 to a full commit SHA instead of mutable tag. Using a major version tag with app secrets (CCCL_AUTH_APP_ID, CCCL_AUTH_APP_PEM) creates supply-chain risk; tag can be retargeted by the action maintainer.
The four project-automation workflows currently leave the workflow
GITHUB_TOKENscope implicit even though they trigger onpull_request_targetandissues(the elevated-context paths).This patch pins each to its minimum:
.github/workflows/project_automation_set_in_review.yml--permissions: {}(workflow scope). Every step authenticates viatibdex/github-app-token@v1.8.0withCCCL_AUTH_APP_ID+CCCL_AUTH_APP_PEM, so the workflow's ownGITHUB_TOKENhas nothing to do..github/workflows/project_automation_set_roadmap.yml-- same shape,permissions: {}..github/workflows/project_automation_sync_pr_issues.yml-- same shape,permissions: {}..github/workflows/triage_rotation.yml--permissions: issues: writeper job. This one does usegithub.token(viaGH_TOKEN: ${{ github.token }}) forgh issue edit --add-label,gh issue comment, and a GraphQLaddAssigneesToAssignablemutation.issues: writeis the minimum that covers all three.Why this matters:
pull_request_targetandissuestriggers run with the default-branch token grant, not the read-only fork-PR grant. Without an explicitpermissions:block, the token gets whatever the repo default is, which can change. Pinning the scope keeps the contract documented in-file and aligns these four withbackport-prs.yml,bench.yml,blackduck-sca.yml, and the rest of the hardened set.Third-party action exposure that motivates the explicit scope:
tibdex/github-app-token@v1.8.0runs inside the workflow context. An explicitpermissions: {}keeps any hypothetical compromise (cf.tj-actions/changed-filesCVE-2025-30066) contained to the app token's installation scope rather than letting it also reach the workflow token.No behavioural change to any of the four.