A common concern/complaint users have with zizmor is that the dangerous-triggers audit is very sensitive: it flags pull_request_target and workflow_run in a blanket fashion.

Users find this annoying because there are (unfortunately IMO) still some common CI/CD tasks that can only be done with these kinds of privileged triggers, like living comments on arbitrary third-party PRs. In a better world GitHub would provide dedicated safer triggers for those kinds of actions, but we don't live in that world.

The challenge is as follows: there are many conceptually safe things users want to do with dangerous triggers, but it's difficult to statically assert that the way they do those things is itself safe. The classic examples of this are dependency bumps on third-party PRs (typically gives the attacker direct code execution in a privileged trigger) and attempting to generate "fancy" comments or similar on PRs (often allows code execution through template injections).

However, these are just the classic examples: pull_request_target and workflow_run are also dangerous because they grant privileged access to an implicit cache token. Beyond this, they're also dangerous because of code injection vectors that can't be caught by template-injection, like GITHUB_ENV and GITHUB_OUTPUT injections.

Finally, there's a basic precautionary argument for not using pull_request_target and workflow_run: they offer a great deal of privilege, and the precautionary principle says that we should assume that attack techniques against GitHub Actions only get better over time.

With all that said, there really is a subset of 100% safe workflows that use dangerous triggers. These workflows tend to have a "stencil" shape where they only use a small subset of 100% safe workflows.

The following actions are known (or presumed) to be 100% safe to use in pull_request_target, since they were designed explicitly by GitHub to be used in that context:

• actions/labeler is explicitly documented for use with pull_request_target
• actions/first-interaction is not documented for use with pull_request_target, but is probably safe
• Probably a small subset of third-party actions, although these would need to be carefully reviewed and only allowlisted at specific known hashes.

So, the basic idea here would be to allow workflows that contain a dangerous trigger if and only if they only have steps that match the set of known safe actions. No other actions or run: blocks would be allowed.

Previous context: #82 #1163