Lack of security tooling

As a big enterprise we lack tooling for Scala to index potential vulnerabilities.

SAST/Linting - Currently we work with SonarQube for reporting incidents, but there is a very limited set of rules. Scalameta/SemanticDB could maybe a part of the puzzle to address this, but maybe there should be a format of which library authors could make linting and SAST instrumentation to find mis-use of their libraries? Also potential mis-use of the std library could be identified? Also reporting this to tools like SonarQube is lacking, which make these issues visible to the business and other devs. Also inherting the JVM/Java eco system makes this quite a challenge

Vulnerability of dependencies - Currently there sbt-dependency-submission to submit the dependencies to github. However not everyone works with github, we would like to have all the security issues in one place (SonarQube). At the moment we use sbt-dependency-check, which needs to download an NVD database each scan and sends it to SonarQube. Here once again, an intermediate format where dependencies of a build a introspectable (sbt is lacking in this regard, no simple TOML/JSON file). Send the list of dependencies to a server. This has a few benefits. First benefit is performance, the sbt-dependency-check is a lengthy/heavy process. Second benefit is that the dependencies are indexed centrally and if a project is not updated for a while and is vulnerable eventually, you know right away.

Thanks for reading my feedback! Feel free to add more feedback

6 Likes

Thanks @Fristi for opening this discussion.

While it is true that we lack a few tools in the security area, I think that all the main components are more or less already there and that we mostly need to integrate them better with the larger infrastructure, SonarQube for instance.

Here are a few hints that I hope will help you.

SAST/Linting

Scalafix is the main linting and refactoring tool for Scala and it supports writing custom rules and importing them. A number of rules contributed by the community can be found in the documentation or in Scaladex.

One of the successful use case of Scalafix is the automated migration of a library version by Scala Steward. Library authors write rules to automate the migration from 2 versions of their library and Scala Steward can run those rules and open PRs. You can learn more about this here.

I don’t know if there exists a tool to run Scalafix and report in SonarQube. Depending on the build tool, the integration could be made by extending the sbt-scalafix plugin, or the mill-scalafix plugin, or the scalafix CLI directly. And it would be a valuable contribution to the ecosystem.

Vulnerability of dependencies

There is an sbt-dependency-tree plugin that is part of the sbt repository and that can generate a JSON file. This JSON file is an internal detail of the dependencyBrowseTreeHTML task but maybe we could change that and exposes it directly as its own task.

To test it, you can install the plugin:

addSbtPlugin("org.scala-sbt" % "sbt-dependency-tree" % "1.7.1")

And then run foo / dependencyBrowseTreeHTML. This task will generate a tree JSON file and an HTML file to browse it manually.

Alternatively it would be possible to fork the sbt-dependency-submission plugin and adapt it to export a JSON file that is more suited to your need.

4 Likes

Thanks for your extensive answer!

SAST/Linting

Scalafix is indeed a tool which makes linting (and migrations) possible, but it’s focus on SAST is lacking. I’ve commented on this existing issue to see if there more interest in adding reporting capabilities to for example SonarQube or a more generic format.

Vulnerability of dependencies

I also already knew about sbt-dependency-tree. I was looking for a tool which keeps track of all the dependencies and such, turns out there is SBOM for this. From Cyclone there is an SBT plugin you can use to submit your dependencies, didn’t try it yet … but looks good to mitigate these risks