Feature: Manual allowlist/denylist for actions (forbidden-uses)

[Holzhaus]

Pre-submission checks

• I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
• I have looked through the open issues for a duplicate request.

What's the problem this feature will solve?

For organizations that are worried about supply-chain security, it can be important to only allow actions that have been reviewed and approved.

Describe the solution you'd like

A new check that outputs a warning if an actions is used that is not on an allowlist.

By default, the check should only allow:

• Official GitHub Actions (actions/*)
• First-party actions (hosted on the same user/organization as the repo itself.

Additional actions could be added to an allowlist (via settings). Inversely, actions that have should not be used could be put into a denylist (and thus always result in high-severity finding).
Since most users don't need this, findings for non-allowlisted actions should probably be suppressed by default.

Additional context

Some ideas for settings:

rules:
  forbidden-uses:
    allow:  # Matching actions will not result in a finding
      - "actions/*"
      - "@self/*"  # Something like this might be used to allowlist first-party actions (?)
      - "some-user/trusted-action"
      - "trusted-org/*"
      - "another-user/action-where-only-a-specific-version-is-trusted@e046bf4c08d98a867ad0fce4a27d3c0d06976598"
    deny:  # Matching actions will result in finding of level error (or warning?)
     - "untrusted-user/*"
     - "some-user/untrusted-action"
     - "another-user/action-where-only-a-specific-version-is-untrusted@5790ee9005aa9399722753077ba64e92947a5727"
     - "*"  # Add this if you want to deny everything that is listed under allow

[woodruffw]

Hi @Holzhaus! I think this is a great idea for a new audit, although there are a few things that need hammering out:

First-party actions (hosted on the same user/organization as the repo itself.

This might need to be tweaked a bit, in terms of how zizmor "sees" it: zizmor isn't aware of the user/org or repo it's running on; all it sees are input files.

Because of that, there isn't a clear first/third party distinction in zizmor itself (except for explicitly 1p actions, e.g. uses: ./something-local).

To work around that, the config would probably need to make no distinction between first- and third-party, just "allow" and "deny." The equivalent of @self/* would be explicitly typing out the user/org slug.

---

Separately, this is a bit of a conventional break with the other audits (since it requires configuration). This is OK IMO, since like you said we can suppress it/skip it entirely when the needed configuration isn't present.

In terms of configuration: instead of having both allow and deny, WDYT about having just one? In other words, users could specify allow or deny, but not both, since having both means that zizmor needs to define precedence/deconflict them instead of just handling one at a time.

Finally, in terms of configuration layout: having allow/deny adjacent to the existing ignore key (for per-file ignores) might be a bit confusing, so we could namespace it a bit further under policy, e.g.:

rules:
  forbidden-uses:
    # policy below does not affect these ignores
    ignore:
      - "not-this-workflow.yml"
    policy:
      # anything NOT listed here is rejected
      allow:
        - "actions" # allow everything under actions/*
        - "my-org" # allow everything under my-org/*
        - "other-org/trusted-action" # allow this exact action, any rev
        - "other-org/also-trusted@v3" # allow this exact action, exact rev

There's also a question of whether foo/bar@tag should resolve tag and also allow matching commit refs, but that's a relatively small thing 🙂

Let me know what you think about the above! It's a bit of a brain dump, so apologies for that.