Report format compatible with the GitLab Dependency Check format

[niklasfi]

Is your feature request related to a problem? Please describe.
It is good practice to have a dependency scanner as part of a ci/cd pipeline. GitLab even has a handy vulnerability overview in merge requests, if you do so. Unfortunately, the dependency scanner supported by GitLab [1] is very much lacking in Java version support. In general, only LTS versions are supported, and even they only arrive half a year after the Java release. Right now, I only have two choices: use the current Java version or have a properly working dependency scanner in my pipeline.

Describe the solution you'd like
GitLab's vulnerability feature is not restricted to using GitLab's scanner. It's possible to provide your own scanner [2]. My proposal to solve the dilemma above is to add a new report format conforming to GitLab's report schema [3].

Describe alternatives you've considered
I have previously implemented a "translator" from DependencyCheck into GitLab's format that ran after DependencyCheck and generated an output file in the desired format. This however feels clunky, when the power of velocities templating language is already at our hands when generating the report file.

Additional context
I have implemented an initial version but I'm missing some additional fields. I will shortly add a pull request to this issue for that.

---

References
[1] gemnasium, which I think uses DependencyCheck inside
[2] documentation: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#reports-json-format
[3] schema definition: https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/raw/v15.0.6/dist/dependency-scanning-report-format.json?ref_type=tags

[aikebah]

Gemnasium uses its own analyzer that hooks into Gitlab's own vulnerability database

https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium

[aikebah]

And from the looks of the documentation at https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#working-around-missing-support-for-certain-languages-or-package-managers

you cannot have it process a JSON report created by another tool, but only have a tool create a supported dependencies input format so that gemnasium can do its work even if your build tool's dependency configuration format is not supported

[aikebah]

So my gut feel is that your approach will turn out not to work

[niklasfi]

@aikebah as mentioned above, I have previously implemented the "conversion tool approach" with good success in gitlab. It definitely works. All we have to do is provide a json in the right format (which we can do with linked template) and mark the artifact as dependency_scanning [1]. Doing it this way avoids gemnasium all together, but the identified dependencies (and vulnerabilities) are still shown in gitlab.

[1] https://docs.gitlab.com/ee/development/integrations/secure.html#artifacts

[aikebah]

@niklasfi Ah right... that looks like a supported scenario indeed. Then most certainly it would be a valuable addition.

[marcelstoer]

Should this be closed as #5920 was merged?

@niklasfi Are these GitLab features limited to certain (enterprise) versions?

[niklasfi]

@marcelstoer I don't have access to a non-ultimate gitlab instance right now, so I can't be 100% sure, but from their documentation ("All offerings") afaik no, these features should be available to everyone.

[aikebah]

@niklasfi @marcelstoer Their documentation tags it as 'ultimate' 'all offerings', which is to say its available on the ultimate EE license, both in their SaaS and their on-prem offerings. So it's on gitlab EE ultimate only.