Migrate Scala SAST coverage from SpotBugs to Semgrep
Problem to solve
GitLab SAST uses various analyzers to scan code for vulnerabilities. For technical reasons, some of these analyzers require building the project that's being scanned.
The need to build code in SpotBugs contributes to a number of problems, as detailed in Migrate Java SAST coverage from SpotBugs to Sem... (#352666 - closed) (which covered Java). Removing build requirements would obviate many of these issues.
User experience goal
The user should be able to run SAST scans against Scala code without having to consider build-time dependencies, runtime environment requirements, or other complications. If they bring source code, we should be able to scan it.
Proposal
Port existing rulesets to Semgrep rules, including Scala-specific rules that were previously omitted in Migrate Java SAST coverage from SpotBugs to Sem... (#352666 - closed).
Change the GitLab-managed SAST CI/CD template to send Scala code to Semgrep instead of SpotBugs. Note: For change rollout reasons, we should first run the scans in parallel with SpotBugs. Only after an appropriate migration and announcement period should we remove Scala from the SpotBugs rules
in the CI/CD template.
Maintain SpotBugs for languages that Semgrep doesn't yet support at GA maturity (Groovy, Kotlin).
Details
Here are the security-related rules currently supported in:
The Programming Languages on GitLab.com Sisense dashboard (internal link; GitLab team members only) shows current estimated usage of Scala in GitLab.com.
We have a longer-term strategy of moving more language analyzers toward Semgrep (&5245 (closed)). While this does not fully remove an existing analyzer, it should significantly shift workload to Semgrep.
Documentation
We would need to update Supported languages and frameworks as well as various examples within the main SAST page.
What does success look like, and how can we measure that?
- Reduced number of SpotBugs analyzer failures would be a primary indicator of success (assuming that build failures currently manifest in these metrics)
- Reduced Support interactions for Scala projects would be a significant indicator of a better user experience
- Reduced number of SpotBugs-related issues in the GitLab issue tracker would similarly indicate that fewer users are having problems
- Reduced SpotBugs analyzer jobs would indicate that the change is actually meaningfully moving our workload from SpotBugs to Semgrep
Steps
The following steps were adapted from the C# Semgrep transition issue.
Translate the rules
-
Add the ability to scaffold Scala projects to the rules-project-scaffolder -
Add a scala
sub-directory to sast-rules -
Add a dummy rule and corresponding test case to sast-rules -
Add .sc
to the set of supported extensions in Semgrep and ensure the MR pipeline generates a Semgrep Docker image with the.sc
extensions enabled. -
Create a migration summary issue according to the C# example. -
Integrate enhanced rules-project-scaffolder + temporary Semgrep Docker image into the CI configuration of the rule-testing-framework. -
Configure the existing spotbugs rule-testing-framework CI job to work with Scala. -
Translate rules and use the rule-testing-framework as a compass to see whether or not we are on par. Document gaps in the sast-rules README.
Release the rules
-
Add the complete Scala ruleset into Semgrep, add a rule ID formatting function, and cut a new release. The rules should be added once #390908 (closed) is complete, by importing them in the dockerfile. -
Add the .sc
extension to the SAST CI template. -
Modify the SAST documentation to mention that Semgrep supports Scala.
Other links / references
Spotbugs scanner insufficient memory for the Ja... (#344022 - closed)
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.