SAST reports wrong paths in Java & Scala sub-projects
Summary
SAST is unable to generate the path of an affected file that belongs to a Java or Scala sub-project or sub-module. The generated path is invalid because SAST simply assume that the file belongs to the top-level project. This affects Gradle submodules as well as Sbt sub-projects (also called subprojects, multiprojects or multi-projects). It probably affects Maven sub-projects too.
This issue affects all the SAST tools built on top of Find Security Bugs.
Steps to reproduce
Enabled AutoDevOps or SAST on a Java Gradle or Scala Sbt project made that has sub-projects. Make sure there's a vulnerability somewhere in one of the sub-projects. Run the pipeline, review the vulnerabilities reported by SAST, then try to open the link to a vulnerability that belongs to one of the sub-projects. The link is broken.
Example Project
To reproduce this issue on a Scala Sbt project, perform SAST on the Silk Framework.
See also this sample Gradle project with multiple modules.
What is the current bug behavior?
Link to the affected code is broken.
What is the expected correct behavior?
Link points to the affected code even if the file belongs to sub-project.
Possible fixes
Since the XML output of Find Sec Bugs doesn't contain the full path of the affected files, the SAST wrapper should go through all the Java or Scala source files and build a map between the full path and what's in the XML output. For instance, here's what would show up in the XML output for Silk:
org/silkframework/learning/generation/ComparisonGenerator.scala
And here's the corresponding full path (relative to the root directory of the repo):
./silk-learning/src/main/scala/org/silkframework/learning/generation/ComparisonGenerator.scala