|
| 1 | +# pylint-sarif |
| 2 | + |
| 3 | +pylint-sarif is a [pylint](http://pylint.org) plugin which allows outputting |
| 4 | +[SARIF][] report files. |
| 5 | + |
| 6 | +[SARIF][] is a standardized structured interchange format used to exchange |
| 7 | +information between static analysis and security tools (e.g. pylint) and |
| 8 | +various types of alert systems, formatters, aggregators, ... |
| 9 | + |
| 10 | +## Usage |
| 11 | + |
| 12 | + pylint --load-plugins=pylint_sarif --output-format=sarif <path to source> |
| 13 | + |
| 14 | +or in `pyproject.toml`: |
| 15 | + |
| 16 | + [tool.pylint.main] |
| 17 | + load-plugins = ["pylint_sarif"] |
| 18 | + |
| 19 | +then pass the `--output-format` still. |
| 20 | + |
| 21 | +Note that pylint supports [multi-output configurations][] so it's possible |
| 22 | +to output e.g. both a machine-readable report to a file and a human-readable |
| 23 | +output to stdout. |
| 24 | + |
| 25 | +## Limitations |
| 26 | + |
| 27 | +[SARIF][] is a massive format, consumers only implements the bits they |
| 28 | +care about (which makes sense), but some of them may require properties |
| 29 | +which are optional per-standard, this reporter primarily targets GitHub |
| 30 | +with the official [SARIF validator][] being a secondary goal[^2]. |
| 31 | + |
| 32 | +Other *production* consumers should have the same status as GitHub (unless |
| 33 | +they are kind enough to remove their extra requirements). One might hope |
| 34 | +they would contribute their requirements as a validation rule but that |
| 35 | +seems challenging[^1]. |
| 36 | + |
| 37 | +### On URIs |
| 38 | + |
| 39 | +The reporter makes use of URIs for artifacts (~files). Per |
| 40 | +["guidance on the use of artifactLocation objects"][3.4.7], `uri` *should* |
| 41 | +capture the deterministic part `of` the artifact location and `uriBaseId` |
| 42 | +*should* capture the non-deterministic part. However as far as I can tell |
| 43 | +pylint has no requirement of (and no clean way to require) consistent |
| 44 | +resolution roots: `path` is just relative to the cwd, and there is no |
| 45 | +requirement to have project-level files to use pylint. This makes the use of |
| 46 | +relative uris dodgy, but absolute uris are pretty much always broken for the |
| 47 | +purpose of *interchange* so they're not really any better. |
| 48 | + |
| 49 | +As a side-note, Github [asserts][relative-uri-guidance] |
| 50 | + |
| 51 | +> While this [nb: `originalUriBaseIds`] is not required by GitHub for the |
| 52 | +> code scanning results to be displayed correctly, it is required to produce |
| 53 | +> a valid SARIF output when using relative URI references. |
| 54 | +
|
| 55 | +However per [3.4.4][] this is incorrect, the `uriBaseId` can be resolved |
| 56 | +through end-user configuration, `originalUriBaseIds`, external information |
| 57 | +(e.g. envvars), or heuristics. |
| 58 | + |
| 59 | +It would be nice to document the "relative root" via `originalUriBaseIds` |
| 60 | +(which may be omitted for that purpose per [3.14.14][], but per the above |
| 61 | +claiming a consistent project root is dodgy. |
| 62 | + |
| 63 | +We *could* resolve known project files (e.g. pyproject.toml, tox.ini, etc...) |
| 64 | +in order to find a consistent root (project root, repo root, ...) and |
| 65 | +set / use that for relative URIs but that's a lot of additional complexity |
| 66 | +which I'm not sure is warranted. |
| 67 | + |
| 68 | +## Prior art |
| 69 | + |
| 70 | +- [pylint2sarif](https://github.com/GrammaTech/pylint-sarif) by @fishoak |
| 71 | + (Paul Anderson, member of the SARIF committee) |
| 72 | +- [`Sarif.Multitool convert`][] advertises pylint json input |
| 73 | + |
| 74 | +## TODO |
| 75 | + |
| 76 | +- Validation test via the official validator? |
| 77 | + |
| 78 | + It's a bit difficult as `Sarif.Multitool` is a C# utility distributed via |
| 79 | + nuget, there is also a distribution via npm (`@microsoft/sarif-multitool`) |
| 80 | + but it's just an installation convenience, it fetches and runs the C# |
| 81 | + package (including a redistributable C# runtime, see |
| 82 | + `@microsoft/sarif-multitool-linux`) |
| 83 | + |
| 84 | +[^1]: the validator seems like a pretty complicated C# project, the |
| 85 | + [Contributing a SARIF Validation Rule](https://github.com/microsoft/sarif-sdk/blob/main/docs/Contributing%20a%20SARIF%20Validation%20Rule.md) |
| 86 | + document is all dead links, and requests have mostly been rotting: |
| 87 | + right now there are 14 "New rule" issues open (8 fixed) and |
| 88 | + 9 "RULE REQUEST" issues (3 fixed, 1 closed as duplicate), looks |
| 89 | + like the primary rules contributor / driver has deleted their |
| 90 | + account and the rest have generally moved away from the project |
| 91 | + (or at least reduced their activity on it) |
| 92 | +[^2]: but it's got a bunch of weird rules which either are nonsensical |
| 93 | + or are not really provided-for by pylint |
| 94 | + |
| 95 | +[SARIF]: https://sarif.info/ |
| 96 | +[SARIF validator]: https://sarif.info/Validation |
| 97 | +[multi-output configurations]: |
| 98 | + https://pylint.readthedocs.io/en/stable/user_guide/usage/output.html#output-options |
| 99 | +[`Sarif.Multitool convert`]: |
| 100 | + https://github.com/microsoft/sarif-sdk/blob/main/docs/multitool-usage.md |
| 101 | +[3.4.4]: |
| 102 | + https://docs.oasis-open.org/sarif/sarif/v2.1.0/csprd01/sarif-v2.1.0-csprd01.html#_Toc10540869 |
| 103 | +[3.4.7]: |
| 104 | + https://docs.oasis-open.org/sarif/sarif/v2.1.0/csprd01/sarif-v2.1.0-csprd01.html#_Toc10540872 |
| 105 | +[3.14.14]: |
| 106 | + https://docs.oasis-open.org/sarif/sarif/v2.1.0/csprd01/sarif-v2.1.0-csprd01.html#_Toc10540936 |
| 107 | +[relative-uri-guidance]: |
| 108 | + https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning#relative-uri-guidance-for-sarif-producers |
0 commit comments