Feature: include `event_triggers` and `permissions` values for workflow in findings

[bthuilot]

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 both the open and closed issues for a duplicate request.

What's the problem this feature will solve?

I perform some open source scanning/bug bounty with this tool and when scanning large amounts of repositories I would like to filter results by which ones have "dangerous" event triggers and/or permissions. (for example contents: write on pull_request_target event)

Describe the solution you'd like

In the output of the findings, two new fields event_triggers and permissions are included in the finding location. the event_triggers should contain the names of the event that can trigger the workflow and the permissions field should contain the computed permissions of the step/workflow (i.e. if the workflow has write for id_token and the step has write for contents, If there is a finding within the step the permissions field should indicate write for both contents and id_token

Additional context

This will make alerting and detection easier for any users who use this tool to either search or continually monitor their workflows.

Happy to get started on a PR if there is interest in this feature!

[woodruffw]

Hi @bthuilot, thanks for opening an issue.

In the output of the findings

Which output? I'm guessing from context you mean the JSON (v1) output, but I want to make sure I'm understanding correctly.

On a high level, I'm hesitant to do this: the output format is internationally agnostic/generic over input types, so adding information that's specific to only workflows would mean specializing it in ways that make it less flexible/generic for future supported input types. It's also inflexible in terms of future extensions, since it means adding more custom fields as more things become interesting to end users.

I think there are two alternatives here:

1. It's possible that there's a new audit that could be useful here, i.e. something like dangerous-triggers but with additional permission checks too. That's something I'd potentially be interested in, but it comes with risks/concerns about alert volume that would need to be addressed in a proposed design.
2. As an end user, you can currently do this yourself by taking the JSON output, filtering unpinned-uses, and the doing your own (very simple) scan over the flagged workflows for dangerous permissions. This wouldn't require any specific changes to zizmor, although it would require some external glue scripting.

WDYT about either of these? If (1) appeals to you, I'd be happy to think through a design there further with you.

[bthuilot]

hey @woodruffw! yes I was referring to JSON V1.

Option 1 totally works (at least for my use-case) so happy to move forward with that!

[woodruffw]

Option 1 totally works (at least for my use-case) so happy to move forward with that!

I think the main thing with (1) is either a design for changing the existing dangerous-triggers audit or a proposal for a new audit that does similar things (but without increasing alert noise too much). Do you have thoughts on either of those?

[bthuilot]

I am fine with either.

I was thinking the audit would report if any permissions are write for actions that can be triggered by an external user (pull_request_target, issue_comment, pull_request_comment, etc.) so up to you if that's better suited in a new audit or not.