Harden the GitHub Actions workflow

[johnbillion]

Split out from #159, this hardens the GitHub Actions workflow in this repo and facilitates changing the Settings -> Actions -> Workflow Permissions setting in this repo to read-only by default.

Combined, these changes greatly minimise the impact that a vulnerability in the CI workflow can have. The current configuration means that if, for example, the crate-ci/typos action was compromised, the write access that this workflow has could be exploited.

1. Tightens the permissions to what is minimally required, namely contents: read for the checkout.
2. Pins the third party action refs so they don't move.
3. Disables credential persistence on the git checkout. Just extra hardening at this point.

This addresses all issues reported by Actionlint and Zizmor. The security team are investigating the best way to apply scanning with those tools across the entire WordPress organisation on GitHub.

[jrfnl]

@johnbillion Thanks for splitting this change off. I'm happy with the proposed changes.

Having said that, this repo does not currently contain a dependabot.yml configuration, so pinning the actions means they will never benefit from new releases, which I also consider risky.
In my opinion, pinning action runners MUST always be combined with a Dependabot config.

Now, considering this repo is low traffic, I'm not keen on adding a "standard" Dependabot config using a weekly schedule as that just means a lot of work for maintainers for very little benefit, so I propose adding a Dependabot config with a (bi-)monthly schedule or even a cron based schedule. Does that sound reasonable to you ?

[jrfnl]

Shouldn't this be updated to v 6.0.2 ?

[GaryJones]

Having said that, this repo does not currently contain a dependabot.yml configuration, so pinning the actions means they will never benefit from new releases, which I also consider risky. In my opinion, pinning action runners MUST always be combined with a Dependabot config.

The point of pinning is to defeat tag-mutation attacks. Whether we then update those pins weekly, quarterly, or yearly, through Dependabot or someone remembering to do it manually, is a separate risk-management decision, but not one that should block the additions of pins IMO.

[jrfnl]

The point of pinning is to defeat tag-mutation attacks. Whether we then update those pins weekly, quarterly, or yearly, through Dependabot or someone remembering to do it manually, is a separate risk-management decision, but not one that should block the additions of pins IMO.

I don't agree. Pinning without setting up Dependabot is creating technical debt, a maintainer burden and a new risk. Solving one risk by introducing another (action pinned to a version for which a vulnerability has been found and disclosed since) does not sound like a reasonable way to "harden" a workflow.

[rodrigoprimo]

I'm inclined to agree with @jrfnl and think it would be preferable to pin the versions together with the introduction of Dependabot in this repository. I'd be happy to create a dependabot.yml file if that would help.