ci: harden CI per Astral's open-source security recommendations

[dunglas]

Adopts the supply-chain practices described in Astral's "Open source
security at Astral" post (https://astral.sh/blog/open-source-security-at-astral)
and applies them to the FrankenPHP CI:

• Add a zizmor workflow that audits every PR/push touching .github
  (and weekly on a schedule) as a hard gate. zizmor is installed via
  pipx so the security workflow itself has minimal supply chain.
• Tighten every workflow to start with permissions: {} and grant the
  minimum permissions per job, so newly added jobs inherit nothing.
• Track Docker base images with Dependabot so security patches in the
  underlying images surface as reviewable PRs.
• Document the hardened posture (zizmor gate, least-privilege perms,
  environment-scoped secrets, build provenance, no pull_request_target)
  in SECURITY.md.
• Document hash-pinning as the next ratchet in zizmor.yaml; the policy
  stays at ref-pin for now to avoid breaking existing tag pins, with
  a clear path to switch to hash-pin once Dependabot starts updating
  by SHA.

[Copilot]

Pull request overview

Hardens the repository’s GitHub Actions CI posture by enforcing least-privilege workflow permissions and pinning third-party actions, aligning with Astral’s supply-chain security recommendations.

Changes:

• Set workflow-level permissions: {} across workflows and add minimal per-job permissions where needed.
• Pin GitHub Actions uses: references to immutable commit SHAs.
• Add a Dependabot auto-merge workflow for non-major GitHub Actions updates and update zizmor policy configuration.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
zizmor.yaml	Tightens unpinned-uses policy (now configured to enforce stronger pinning).
.github/workflows/wrap-issue-details.yaml	Drops default permissions and pins actions/github-script by SHA.
.github/workflows/windows.yaml	Drops default permissions and SHA-pins key actions in Windows build workflow.
.github/workflows/translate.yaml	Moves permissions to job scope and SHA-pins actions used for translation + PR creation.
.github/workflows/tests.yaml	Adds job-scoped contents: read and SHA-pins actions used in test jobs.
.github/workflows/static.yaml	Adds job-scoped permissions and SHA-pins Docker/Actions dependencies (incl. provenance attestation action).
.github/workflows/sanitizers.yaml	Adds job-scoped contents: read and SHA-pins checkout/go/cache actions.
.github/workflows/lint.yaml	Moves permissions to job scope and SHA-pins checkout + super-linter.
.github/workflows/docker.yaml	Adds job-scoped permissions and SHA-pins Docker/Actions dependencies.
.github/workflows/dependabot.yaml	Introduces a Dependabot PR auto-merge workflow and SHA-pins metadata action.
.github/actions/watcher/action.yaml	SHA-pins actions/cache used by the composite action.

Comments suppressed due to low confidence (1)

zizmor.yaml:6

• The PR description says the zizmor policy will stay at ref-pin for now, but this change switches it to hash-pin. Either update the PR description/SECURITY docs to match, or keep the policy at ref-pin until the repo is ready to enforce hash pinning everywhere.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[withinboredom]

Hear me out. This logic seems kinda circular? Lock down all the things to prevent supply-chain attacks ... but then auto-merge updates, which is the most likely vector for supply-chain attacks?

Don't get me wrong, I completely agree with this workflow (automating updates FTW). Just pointing out the logic.

[henderkes]

I'm against dependabot auto merges. Most of the time it's broken and even in case it does manage to get a working PR, it's likely that it missed other packages, so we need to manually touch it up anyway. Auto merges in general are also a bit tricky in my eyes, many vulnerabilities and projects takeovers have been achieved by auto CI runs or merges.

[withinboredom]

I'm also not a fan of SHAs for these same reasons. Dependabot updates the SHA and the comment ... but I still got to go check the SHA is actually what the comment says, which is a branch head. At that point, might as well lock it to the branch instead of the SHA.

[dunglas]

With the cooldown period, this gives some time for the supply chain attacks to be detected (not the case currently), while not increasing maintenance burden for us (currently, new minor versions of our GitHub Actions dependencies are automatically used).

[dunglas]

Pinning to SHA also provides better traceability and reproducibility: we can easily know what exact versions of all our dependencies have been used to build a release.

[dunglas]

WDYT about this one @php/frankenphp-collaborators? #2347 (comment)

[withinboredom]

I have mixed feelings about it.

The cooldown only works as long as someone else is willing to run the branch HEAD and be the canary. If everyone adopts the same cooldown ... it stops serving any defensive purpose; we're just waiting an extra week for real bugfixes. We're effectively free-riding on people being less cautious than us, and the more widely the pattern spreads, the less it actually buys anyone.

On SHA pinning: reproducibility feels like a logging concern rather than an implementation one. We can resolve the SHA at build time -- its in the logs -- without giving up the "we're running v4" at-a-glance. And pinning creates its own maintenance pain ... if a commit lands in both v4 and v5 (cherry-picks happen), which version does the pin represent? We're back to trusting the comment, which defeats the point.

Extending @henderkes's reliability concern: imagine dependabot updates us to a SHA that turns out to have a known issue. We downgrade. On dependabot's next run, it'll just re-upgrade us to the same broken SHA, and it won't pick up the hotfix commit because the hotfix hasn't cooled down yet. So we're exposed to the bug through the first cooldown window, then locked out of the fix through the second ... cooldown can introduce a failure mode rather than mitigating one.

I acknowledge these are edge cases, but these are new edge cases that currently don't exist. This is mostly where my concerns lie. If we acknowledge these new cases and have a way to deal with them; then 🚢 it.

[AlliBalliBaba]

I think I like the SHA pinning, I can see it preventing certain supply chain attacks, even if there's some cost to maintainability.

I dislike the auto-merges though since (as already mentioned) updates might also silently break stuff. Maybe that almost never happens, we can also trial it.

[dunglas]

Do you all agree to trialing it? We'll roll it back if it proves to be annoying. Regarding your concerns @withinboredom, I'm certain many projects like to live on the edge, but since FrankenPHP is becoming a critical piece of infrastructure, I don't think it's the right place to test the latest versions of GitHub Actions. Also, most actions we use are maintained by major companies (Microsoft, Docker, etc.) that likely "dogfood" their own products first and don't need us to beta-test for them.

[henderkes]

I'm still not a fan of the auto updates and merges for the reasons outlined earlier, but I agree with pinning to commit hashes.

(Microsoft, Docker, etc.) that likely "dogfood" their own products first and don't need us to beta-test for them.

Sorry, but I had to grin reading that.

I'll bring up my primary concern again:

Auto merges in general are also a bit tricky in my eyes, many vulnerabilities and projects takeovers have been achieved by auto CI runs or merges.

This is something we shouldn't roll out, unless we're 100% sure it cannot have negative consequences. If you are, I don't object to merging it, though I would prefer to remove the auto merge part because it will likely not have anything useful come of it anyway.

[dunglas]

Automatic merging is quite similar to what we have now by referencing major version only isn't it?

[henderkes]

Oh, the automatic merge is limited to gha minor and patch updates. That still kind of defeats zizmor's point, but doesn't trigger what worried me. I understood that all dependabot updates would always be auto merged.

[alexandre-daubois]

This branch is behind #2369, which dropped environment: dockerhub from the DockerHub jobs and added the secrets-outside-env allowlist for DOCKERHUB_TOKEN to zizmor.yaml instead. Deleting zizmor.yaml here removes that allowlist, which the zizmor lint gate now relies on, so the gate breaks. Maybe the rebase will solve this?

[dunglas]

Are you ok to merge the last version of this one @php/frankenphp-admin?

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 2 comments.