ci: adjust zizmor advanced security handling

[wochinge]

What changed

• Run zizmor-action with advanced-security: false for non-push events, including pull requests and merge queue runs.
• Keep Advanced Security/SARIF uploads enabled on push events.
• Set min-severity: low for the zizmor scan.

Why

Fork pull requests cannot upload code scanning results to GitHub Advanced Security, so requiring zizmor code scanning results blocks community PRs. This keeps the check usable for fork PRs while preserving SARIF upload on trusted pushes.

Validation

• YAML parse check for .github/workflows/zizmor.yml
• git diff --check -- .github/workflows/zizmor.yml

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
langfuse-js	Ready	Preview	May 21, 2026 8:56am

[github-actions]

@claude review

[claude]

LGTM, straightforward CI workflow change to support fork PRs in zizmor scanning.

Extended reasoning...

Overview

This PR modifies a single CI workflow file (.github/workflows/zizmor.yml). It removes the if: guard that previously skipped the job for fork PRs, adds the security-events: write permission, makes advanced-security conditional on push events (so fork PRs run the scan without attempting SARIF upload, which would fail), and lowers min-severity from medium to low.

Security risks

Minimal. security-events: write is the standard permission required for SARIF uploads on push, and is gated to push events for the actual upload behavior via advanced-security. Fork PRs receive only read-scoped tokens at GitHub's level, so the elevated permission on the job has no effect for untrusted runs. The pinned action SHA is unchanged.

Level of scrutiny

Low. This is purely a CI configuration change — no runtime, build artifact, or production code is touched. The change is mechanical and follows the documented zizmor-action pattern for handling fork PRs.

Other factors

One minor note: the prior code had a comment explaining that advanced-security: false was used to avoid blocking the release workflow that pushes directly to main. The new logic re-enables advanced-security on push events, which could theoretically re-introduce that blocking behavior if the release workflow triggers findings — but this is a risk the author has presumably weighed, and the lower severity threshold suggests intent to surface more issues. Worth flagging but not approval-blocking.