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.