Dependency Scanning support added for sbt 1.3.0

Release notes

https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers

Users with scala projects using sbt 1.3+ can now leverage Dependency Scanning. Previously only scala users with <1.3 were supported because we supported ivy, we now support both ivy and coursier dependency managers.

Problem to solve

Dependency Scanning support for scala projects using sbt is not compatible with projects using sbt 1.3+.

After 1.3+, sbt uses coursier as a default dependency manager, rather than ivy. As gemnasium-maven relies on an ivy report generated by the sbt-dependency-graph plugin, processing of coursier projects fails.

Intended users

• Sasha (Software Developer)

User experience goal

Proposal

In order to be compatible, gemnasium-maven needs to add support for the coursier dependency manager.

Further details

The gemnasium-maven analyzer uses the sbt-dependency-graph plugin to create a graph of the scanned project's dependencies. The graph currently created uses the ivyReport format which only works with the ivy dependency manager. The analyzer needs to change the output format. One that supports both ivy and coursier

There are 2 modes that are available which render a dependency graph (required by #229818 (closed)): dot and graphml. The decision to use one of these should be based on robustness of representation and community support for this format. The weight for either choice ought to be similar as golang parsers exist for both of these formats.

Note: Based on further investigation it seems that dot is much more robustly supported as a golang lib and a module we already use (gonum) builds in basic parsing (dot -> graph) for this format.

Additionally: The sbt-dependency-graph README states: Note: Under sbt >= 1.3.x some features might currently not work as expected or not at all (like dependencyLicenses) - the solution should validate different dependency configurations to make sure dependency processing is robust. One concrete robustness criterion should be for dependency scanning of sbt sub-projects.

Implementation Plan

• add QA job to gemnasium-maven that demonstrates sbt 1.3.0 support; this QA job uses an existing branch of tests/scala-sbt, or else a new branch
• update the sbt builder of gemnasium-maven to generate an sbt dependency report using a call to dependencyDot of the sbt-dependency-graph plugin (ensure that this functionality works in sbt 1.4 as the plugin is in-sourced: #271345 (comment 444624604))
• add new dependency file parser to gemnasium, to process the dot file and generate a dependency graph (we already use gonum/graph), and enable this parser in gemnasium-maven
• if possible, remove the parser that processes ivy reports from gemnasium
• double-check the gemnasium-maven offline functionality (https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven/-/blob/master/Dockerfile#L36, https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-maven/-/tree/master/utils/sbt-dependency-graph-plugin) to ensure that inclusion of the plugin continues to work in offline mode given the fact that the plugin was in-sourced in sbt 1.4

Permissions and Security

Documentation

• Dependency Scanning documentation needs to be updated to document support for coursier.

Availability & Testing

• test sbt < 1.3 (existing)
• test sbt 1.3 (needs to be added)
• test sbt 1.4 since usage of the sbt-dependency-graph plugin and some functionality may have changed

Involved components

Analyzers:

• gemnasium-maven needs to be updated
• gemnasium needs to be updated

Tests:

• scala-sbt

What does success look like, and how can we measure that?

• Users using sbt 1.3+ should be able to use Dependency Scanning with their projects.

What is the type of buyer?

Is this a cross-stage feature?

Links / references

• Original report: dependency_scanning + sbt: shouldn't use ivyReport with sbt 1.3.0+
• sbt-dependency-graph: https://github.com/sbt/sbt-dependency-graph