Sebastian Schuberth

As #5651 is merged now which conflicts with this PR, I'll close this one.

More semi-related news on that general topic: https://github.blog/2020-10-05-announcing-third-party-code-scanning-tools-static-analysis-and-developer-security-training/

Also see the very interesting discussion at https://github.com/detekt/detekt/issues/3045 with folks from GitHub / Microsoft. In particular, the *detekt* project now provides a [SARIF library for Kotlin](https://github.com/detekt/sarif4j).

@jonico, is there also a way to see the alerts directly in the "files" tab of the PR which introduces them?

> In order to compute and display the "delta", the base branch would need at least one analysis before with uploaded SARIF results. Ah, thanks for that bit of information!...

AFAIK no one is actively working on this, so far it was more or less just an idea. And I'm not even sure if SARIF is suitable for the kind...

The point is that ORT does (in most cases) not parse the package manager files, and as such also does not really know what dependency is declared in which line.

It really depends on the package manager and its capabilities how ORT analyzes the dependencies. For Gradle, we are using the Gradle Tooling API and no external script, and I'm...

Looks like [SARIF does not *require* to have a location](https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html#_Toc34317670) (plus annotation with a `startLine`) listed after all. So we should be able to write a generic reporter (not starting...

> I don't see much value if we can't pinpoint the file where to apply the change. We seem to have different priorities then. To me, SARIF is just one...