Include Gradle build dependencies (i.e. plugins)

[rnett]

What is the functionality you want to propose?

Gradle dependency analysis should include plugins (and their transitive deps) and other build-time dependencies.

What is the use-case for your enhancement?

Both checking for CVEs and reading sources.

Alternatives you have considered

N/A

Additional context

This can be done super easily by also adding buildscript.configurations here. I don't know if you handle build time dependencies differently in the reports, but IMO it would be a good idea. You might want to make them use buildscript:<name> scope names or similar too.

[sschuberth]

Thanks for the suggestion!

Historically, we've considered build system plugins / dependencies to be out of scope as they're not part of the software product's distribution. However, this was coming very much from the license compliance view of things, where only what's distributed matters. Now that ORT evolved more into the security and software quality domains, I do see some value in reporting build system dependencies, too, esp. if it's easy to do. I believe https://github.com/gradle/github-dependency-graph-gradle-plugin does this as well.

But this would somewhat create an inconsistency with our other package manager analyzers, like for Maven, where we do not support reporting build system dependencies either. So we should probably hide this feature behind a feature toggle that is disabled by default.

Putting build system dependencies into a dedicated scope indeed sounds like the most straight-forward solution.

Would you be willing to make a contribution, @rnett?

[rnett]

Sure, I'll take a look at it. Is there prior art for npm dev dependencies or similar I should look at?

[sschuberth]

No other package managers in ORT so far support getting the dependencies of build system plugins. And I'd also consider NPM devDependencies (which we get here) to be something different: To me, they're more like mapping to Gradle compileOnly / testImplementation configurations. In that sense there's no prior art to look at.

The way I'd approach is to make the envisioned changes to OrtModelBuilder.kt and then run GradleFunTest.kt (and the other funTests as well) to get the diff to the expected results. These should be inspected for validity to see whether they match the new expectations, and then be committed along with the code changes.

It might be that you also need to adjust the logic in Configuration.isRelevant() to not discard any configuration coming in via project.buildscript.configurations.

Oh, and one more thing: Don't get confused by the fact that GradleFunTest.kt (and others) from the gradle-inspector module get their test projects from the "legacy" gradle module. We're sharing test assets here (in a more or less dirty way), but both modules maintain they expected results separately, as they're different (gradle-inspector is supposed to work better than gradle).