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.