Migrate Scala SAST coverage from SpotBugs to Semgrep
### Problem to solve GitLab SAST uses various [analyzers](https://docs.gitlab.com/ee/user/application_security/sast/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 #352666+ (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 https://gitlab.com/gitlab-org/gitlab/-/issues/352666+. Change the [GitLab-managed SAST CI/CD template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-manually) 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](https://semgrep.dev/docs/language-support/) at GA maturity (Groovy, Kotlin). ### Details Here are the security-related rules currently supported in: - [SpotBugs](https://spotbugs.readthedocs.io/en/latest/bugDescriptions.html#xss-servlet-reflected-cross-site-scripting-vulnerability-in-error-page-xss-request-parameter-to-send-error) - [find-sec-bugs](https://find-sec-bugs.github.io/bugs.htm) The [Programming Languages on GitLab.com Sisense dashboard](https://app.periscopedata.com/app/gitlab/635927/Programming-Languages-on-GitLab.com) (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 (https://gitlab.com/groups/gitlab-org/-/epics/5245). 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](https://docs.gitlab.com/ee/user/application_security/sast/#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](https://gitlab.com/gitlab-org/gitlab/-/issues/347258). #### Translate the rules * [x] Add the ability to scaffold Scala projects to the [rules-project-scaffolder](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/rule-testing-framework/rules-project-scaffolder) * [x] Add a `scala` sub-directory to [sast-rules](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules) * [x] Add a dummy rule and corresponding test case to [sast-rules](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules) * [x] Add `.sc` to the set of supported extensions in [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/0bc9c6749a06852deba1f8405709ca6b0ca53eef/plugin/plugin.go#L15) and ensure the MR pipeline generates a Semgrep Docker image with the `.sc` extensions enabled. * [x] Create a migration summary issue according to the [C# example](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules/-/issues/27). * [x] Integrate enhanced [rules-project-scaffolder](rules-project-scaffolder) + temporary Semgrep Docker image into the CI configuration of the [rule-testing-framework](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/rule-testing-framework). * [x] Configure the existing spotbugs rule-testing-framework CI job to work with Scala. * [x] 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](https://gitlab.com/gitlab-org/secure/gsoc-sast-vulnerability-rules/playground/sast-rules/-/blob/main/README.md). #### Release the rules * [x] Add the complete Scala ruleset into Semgrep, add a [rule ID formatting function](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/0bc9c6749a06852deba1f8405709ca6b0ca53eef/convert.go#L56-82), and cut a new release. The rules should be added once https://gitlab.com/gitlab-org/gitlab/-/issues/390908 is complete, by importing them in the dockerfile. * [x] Add the `.sc` extension to the [SAST CI template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L242). * [x] Modify the [SAST documentation](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) to mention that Semgrep supports Scala. ### Other links / references https://gitlab.com/gitlab-org/gitlab/-/issues/344022+ _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._
issue