Skip to content

ci: declare minimum permissions on fork-preview-deploy workflow#1714

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

ci: declare minimum permissions on fork-preview-deploy workflow#1714
arpitjain099 wants to merge 1 commit into
ruby:masterfrom
arpitjain099:chore/declare-workflow-perms

Conversation

@arpitjain099
Copy link
Copy Markdown

Declares a top-level permissions block on .github/workflows/fork-preview-deploy.yml with the two scopes the workflow actually uses: actions: read (the actions/download-artifact step pulling from another workflow_run via run-id, and the github-script step calling listJobsForWorkflowRun) and contents: write (the createDispatchEvent API call that triggers the deploy). The workflow runs on workflow_run which executes in the default-branch context with full repo-level token access by default; pinning here keeps that authority bounded.

This is defense-in-depth grounded in CVE-2025-30066 (the March 2025 tj-actions/changed-files supply-chain attack). A compromised third-party action can exfiltrate GITHUB_TOKEN from workflow logs, and the leaked token retains whatever scope it was issued with. workflow_run triggers are particularly attractive because they run trusted and inherit the default scope. The in-file declaration also gives drift protection if the org default ever widens and is what OpenSSF Scorecard's Token-Permissions check credits.

YAML validated locally with yaml.safe_load.

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
@arpitjain099 arpitjain099 requested a deployment to fork-preview-protection May 14, 2026 16:58 — with GitHub Actions Waiting
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.

1 participant