Add SARIF output support

[jawnsy]

I did a cursory search of the code and didn't find anything related, so I believe this is a feature request. The only reference to "SARIF" that I found was a comment from a few weeks ago: #1546 (comment)

Summary

Add a flag to output SARIF data during a run, instead of, or in addition to, the existing output.

Description

GitHub's CodeQL can ingest SARIF files during builds, so that we can track lint issues over time and surface issues inline on diffs. These can be uploaded during pull request builds as well as push event builds.

The trivy code/container image scan tool supports SARIF format, and this is very helpful for open source projects (since CodeQL is free there) as well as for companies using CodeQL.

[charliermarsh]

Makes sense! I'll admit that I know nothing about the format so will have to look into it when I have some time.

Of course, would also make for a great PR if anyone is interested!

[padmano]

I can work on this.

[edgarrmondragon]

@padmano are you working on this?

[padmano]

Yes @edgarrmondragon.

[zanieb]

I'm looking into this a bit and figure I'll share some resources

There's a bandit formatter plugin at microsoft/bandit-sarif-formatter — you can see the implementation details in formatter.py. They lean on some generated Python models and Microsoft also publishes a CLI tool which may be useful for testing.

The latest SARIF specification is available as a JSON schema.

@padmano are you still actively working on this? Could you link to a branch here so people don't have to ask?

[C-Hipple]

I've also been playing with this a bit lately. My branch is here: https://github.com/astral-sh/ruff/compare/main...C-Hipple:dev-add-sarif-output-support?expand=1

Approach so far was copy/paste the json emitter and then I'm going to just change up the formatting. Once it's working i'll clean up the copy/paste and see what can easily be reused without getting too complicated. Probably not too much will end up shared since sarif files group results per rule found, so Serialize for ExpandedMessages is going to look completely different.

What I still need to figure out in Ruff is the best way to get all of the rules which are enabled, since sarif files expect the full list even if there aren't findings for each run. I started in my last commit with a with_applied_rules builder method but it doesn't look like the EmitterContext has what I need, and I don't really want to re-parse the pyproject.toml file. I haven't spent too much time looking around here yet, but any direction would be appreciated (maybe there's a global settings singleton i'm missing?)?

[C-Hipple]

^^ Found some time and resolved the issues above, now it's just about finding the time to format the json as the sarif format.

[C-Hipple]

#9078 PR is here

[charliermarsh]

Thank you @C-Hipple! Look forward to reviewing. Should be able to turn this around pretty quickly.

[C-Hipple]

Thank you @charliermarsh , no big rush though, I have it as a draft since I need to work out a few CI issues and possibly tweak a few other things

[charliermarsh]

This merged as #9078. Thanks @C-Hipple!