Adds zizmor sarif

[kingbuzzman]

A followup to a comment @webknjaz made.

Related to #1203 but not dependent on it.

---

Adds the issues directly onto the PR (this was the example)

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[webknjaz]

This won't work unless you give the job the security events privilege.

[kingbuzzman]

This won't work unless you give the job the security events privilege.

@webknjaz But it did.. what am i missing?

[webknjaz]

Dunno, maybe because it's a public repo?

Let's ask @woodruffw to share ideas...

[kingbuzzman]

@webknjaz OK, I added the permission.. doesnt seem like it matters, but I'd be glad to see your approval 😇 -- if its warranted.

[webknjaz]

Sure, approving. Regarding the sh hack, it would probably be more elegant in a toxfile.py...

[woodruffw]

Dunno, maybe because it's a public repo?

Let's ask @woodruffw to share ideas...

Thanks for the ping -- that might be incidentally working if your GITHUB_TOKEN defaults are the old ("permissive") ones.

You can see that under Actions > General in the repo's settings, or potentially under the org-level settings if you have an org-level permissive policy. For example, this is what I have on zizmor itself:

(it's faded out because I have it disabled on the org level.)

[woodruffw]

The above can happen if this repo is older, since older repos are "grandfathered" into the old permissive token defaults. For example, here's a random older repo of mine:

[webknjaz]

@woodruffw I see, but wouldn't the workflow-level permissions setting reset it to zero privileges? And then the job-level one setting just one privilege (in the previous commit).

[woodruffw]

I see, but wouldn't the workflow-level permissions setting reset it to zero privileges? And then the job-level one setting just one privilege (in the previous commit).

Hmm, true. Yeah, I'm at a loss to explain this, then...

[webknjaz]

@woodruffw I remember how some privileges are needed for private repos and not for public ones. Wonder if this is the case here.

[woodruffw]

Could be that, although I thought that was the case only for the contents and actions permissions with read (since they're "latent" with a public repo). security-events: write OTOH should never be latently present except in a an older default token case, which as you've noted doesn't seem to be applicable here.

[woodruffw]

Hmm, it's also possible there are two different things here: GH might allow "advanced security" to make notifications/alerts on the enabling PR, but then forbid alerts within the security pane itself after merge if the permission isn't set. That would be pretty confusing on GH's part, but it would explain the observed behavior here...

[kingbuzzman]

@webknjaz i've been playing around with toxfile.py.. i dont like the alternative, i prefer the hack. @bluetech do i have your blessings to merge?

[webknjaz]

@woodruffw well, thanks for entertaining my assumptions.. Will leave it as is.

[bluetech]

LGTM, except a comment about using sh in tox