[BUG]: SARIF presentation on GH is broken (again)

[woodruffw]

Pre-submission checks

• I am not filing a feature request. These should be filed via the feature request form instead.
• I have looked through the open issues for a duplicate report.

Expected behavior

SARIF should preview correctly on GitHub.

Actual behavior

Looks like this regressed again, because of some (otherwise good) changes to relative path handling.

In particular, it looks like GitHub's SARIF consumer can handle relative paths like foo/bar fine, but they don't currently handle ./foo/bar.

Consequently, findings get rendered without a correct preview:

Reproduction steps

See above.

Logs

Additional context

No response

[woodruffw]

xref #572

[vivodi]

I can confirm that this issue exists, and even if a PR contains a vulnerability, GitHub Advanced Security does not flag it. I believe this is a serious issue, as this bug could lead to PRs with security risks being merged into the repository.

[woodruffw]

I can confirm that this issue exists, and even if a PR contains a vulnerability, GitHub Advanced Security does not flag it. I believe this is a serious issue, as this bug could lead to PRs with security risks being merged into the repository.

Sorry, could you say more? GHAS should still be flagging/failing PRs when a check fails even if it can't render the check's results, if you configure it to do so. If that is indeed not working, then that suggests a pretty bad bug on GHAS's side, one that I can prioritize working around here but ultimately needs to get addressed upstream too.

[vivodi]

I can confirm that this issue exists, and even if a PR contains a vulnerability, GitHub Advanced Security does not flag it. I believe this is a serious issue, as this bug could lead to PRs with security risks being merged into the repository.

Sorry, could you say more? GHAS should still be flagging/failing PRs when a check fails even if it can't render the check's results, if you configure it to do so. If that is indeed not working, then that suggests a pretty bad bug on GHAS's side, one that I can prioritize working around here but ultimately needs to get addressed upstream too.

See this: https://github.com/vivodi/testzizmor/pull/1 @woodruffw

[woodruffw]

See this: vivodi/testzizmor#1 @woodruffw

Thanks for sharing. There are two different things here: GHAS seemingly won't produce comments if it can't generate the preview, but it can still block the PR if you configure it to do so.

To do that, you need to configure a ruleset that requires the check, and then set an appropriate protection rule under "Code security":

IMO this should be the default, but I imagine GitHub can't change it for compatibility reasons.

[vivodi]

See this: vivodi/testzizmor#1 @woodruffw

Thanks for sharing. There are two different things here: GHAS seemingly won't produce comments if it can't generate the preview, but it can still block the PR if you configure it to do so.

To do that, you need to configure a ruleset that requires the check, and then set an appropriate protection rule under "Code security":

IMO this should be the default, but I imagine GitHub can't change it for compatibility reasons.

I see. Previously, after configuring Zizmor, I noticed that GitHub Advanced Security didn't report any errors. I kept checking, thinking I had misconfigured something.

I think if this bug can't be fixed in the short term, it should be mentioned in the documentation. https://woodruffw.github.io/zizmor/usage/#use-in-github-actions

[woodruffw]

I think if this bug can't be fixed in the short term, it should be mentioned in the documentation. woodruffw.github.io/zizmor/usage#use-in-github-actions

My plan is to have it fixed with the next release -- I'm currently talking with some GH folks to understand whether they can perform an upstream fix here, or whether I need to further tweak how zizmor emits paths in SARIF files.