Skip to content

ci: GitHub Actions workflow security cleanup#361

Open
emptyhammond wants to merge 5 commits into
mainfrom
worktree-fixup-workflows
Open

ci: GitHub Actions workflow security cleanup#361
emptyhammond wants to merge 5 commits into
mainfrom
worktree-fixup-workflows

Conversation

@emptyhammond
Copy link
Copy Markdown

Routine hygiene pass over the four GitHub Actions workflows in this
repo, addressing findings from a security audit. The changes are
split into five commits, one per finding type:

  • pin actions to commit SHAs (tag kept as a trailing comment)
  • set persist-credentials: false on every checkout step
  • add explicit least-privilege permissions blocks
  • move workflow_dispatch inputs in cdn.yml through env vars instead
    of inline shell template expansion
  • explicitly opt out of package-manager caching on the release
    workflow's setup-node

No behavioural change is expected: pinned SHAs resolve to the same
commits the existing tags point at today, and the cdn.yml shell
command produces the same S3 URL it did before.

Replace mutable tag references with full commit SHAs (with the
original tag preserved in a trailing comment) so workflow runs are
reproducible and resistant to tag-retargeting.
Set persist-credentials: false on every actions/checkout so the
default GITHUB_TOKEN is not left in the local git config for later
workflow steps that do not need it.
Add an explicit top-level permissions block of contents: read to the
build/test and Renovate workflows so the implicit broad default
GITHUB_TOKEN scope is no longer granted. The docs job retains its
existing id-token and deployments write scopes, with contents: read
added back since a job-level block replaces the workflow default.
Move github.event.inputs.bucket and github.event.inputs.version out
of the shell template-expansion path and into env vars referenced as
quoted variables, so the values never become inline shell text at
the time the run step is constructed.
In a release-trigger workflow, restoring a previously written cache
during build can compromise the published artifact. setup-node v4
does not enable caching by default, but later versions do; set
package-manager-cache: false so the opt-out is explicit and survives
a future major-version bump.
@emptyhammond emptyhammond requested a review from VeskeR May 26, 2026 10:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant