JFrog reports a go.mod file as being in the root when it isn't

[lukaspj]

Describe the bug

We just tried installing frogbot and running it in our repository, it finds several go.mod files in subdirectories and reports vulnerabilities just fine.
However, it then reports the vulnerability on go.mod in the root directory, where there isn't any, and subsequently fails to generate fix PRs:

Current behavior

I can't share too much of the code and logs, but I can say that this works just fine in another repository with a single go.mod file in a subdirectory, but in this repository there are multiple go.mod files in subdirectories.

Configuration:

with:
    version: latest
  env:
    JF_URL: https://<url>/
    JF_USER: ***
    JF_PASSWORD: ***
    JF_GIT_TOKEN: ***

14:07:19 [Info] Running SCA scan for go vulnerable dependencies in /tmp/jfrog.cli.temp.-1714399604-2368152455/.pages directory...
  14:07:19 [Info] Calculating Go dependencies...
  14:07:19 [Info] Running 'go mod graph' in /tmp/jfrog.cli.temp.-1714399[60](https://github.com/LEGO/novus-platform/actions/runs/8879975780/job/24378990209#step:3:61)4-2368152455/.pages
  14:07:19 [Info] Running 'go list -mod=mod -f {{with .Module}}{{.Path}}:{{.Version}}{{end}} all' in /tmp/jfrog.cli.temp.-1714399604-2368152455/.pages
  14:07:19 [Info] Running 'go list -mod=mod -m' in /tmp/jfrog.cli.temp.-1714399604-2368152455/.pages
  14:07:19 [Info] Scanning 2 go dependencies...
  14:07:20 [Info] Waiting for scan to complete on JFrog Xray...
  14:07:20 [Info] Running SCA scan for npm vulnerable dependencies in /tmp/jfrog.cli.temp.-1714399604-2368152455 directory...
  14:07:20 [Info] Calculating npm dependencies...
  14:07:22 [Info] Scanning 558 npm dependencies...
  14:07:22 [Info] Waiting for scan to complete on JFrog Xray...
  14:07:39 [Info] Xray scan completed
  14:07:40 [Info] The complete scanning results have been uploaded to your Code Scanning alerts view
  Error: 1 [Error] the following errors occured while fixing vulnerabilities in '/tmp/jfrog.cli.temp.-1714399604-2368152455':
  failed to update go dependency: 'go get golang.org/x/[email protected]' command failed: exit status 1
  go: go.mod file not found in current directory or any parent directory.
  	'go get' is no longer supported outside a module.
  	To build and install a command, use 'go install' with a version,
  	like 'go install example.com/cmd@latest'
  	For more information, see https://golang.org/doc/go-get-install-deprecation
  	or run 'go help get' or 'go help install'.
  Error: The process '/opt/hostedtoolcache/frogbot/[RELEASE]/x64/frogbot' failed with exit code 1

Reproduction steps

No response

Expected behavior

No response

JFrog Frogbot version

2.20.2

Package manager info

Go modules

Git provider

GitHub

JFrog Frogbot configuration yaml file

No response

Operating system type and version

ubuntu-latest

JFrog Xray version

No response

[attiasas]

Hi @lukaspj,

Thank you for bringing this issue to our attention. This is a known issue that we are currently aware of.

Currently, we cannot fix CVE-discovered issues for repositories with multiple sub-directories without adding specific configurations. We have plans to enhance our support to remove this requirement in future versions, once we have prioritized this task.

If you have a repository with multiple go.mod files, I suggest you utilize our Frogbot configuration and add each directory path that holds the go.mod file to the workingDirs attribute.

After adding this configuration, it should also work for this repository.

Please feel free to let us know if any other issues arise or if you have further questions regarding this matter. Thank you.

[lukaspj]

For our purposes, a short term fix is just fine!

I’m curious about the technical limitations though, since the working directory is clearly detected and available during the scanning phase, it’s only the fixing phase that is failing.

Is it because the path is lost during XRay scanning? Is that also why it doesn’t show affected files in the GitHub security tab?

What I'm talking about is this part of the logs:

11:04:35 [Info] Preforming 4 SCA scans:

  [
    {
      "Technology": "go",
      "WorkingDirectory": "/tmp/jfrog.cli.temp.-1714475072-1368965406/.pages",
      "Descriptors": [
        "/tmp/jfrog.cli.temp.-1714475072-1368965406/.pages/go.mod"
      ]
    },
    {
      "Technology": "go",
      "WorkingDirectory": "/tmp/jfrog.cli.temp.-1714475072-1368965406/<path>",
      "Descriptors": [
        "/tmp/jfrog.cli.temp.-1714475072-1368965406/<path>/go.mod"
      ]
    },
    {
      "Technology": "go",
      "WorkingDirectory": "/tmp/jfrog.cli.temp.-1714475072-1368965406/<path>",
      "Descriptors": [
        "/tmp/jfrog.cli.temp.-1714475072-1368965406/<path>/go.mod"
      ]
    },
    {
      "Technology": "npm",
      "WorkingDirectory": "/tmp/jfrog.cli.temp.-1714475072-1368965406",
      "Descriptors": [
        "/tmp/jfrog.cli.temp.-1714475072-1368965406/package.json"
      ]
    }
  ]

[lukaspj]

Ah I see, at this point it has already gone kindda wrong because this is not 4 different projects, but a single project with 4 different roots and it gets confused because there are more than one Go root

[attiasas]

@lukaspj,

The code for detecting and fixing the issues is located in different repositories and projects. We are utilizing our audit CLI command to detect the issues, while Frogbot can also implement fixes for them. The log you shared is part of this process when we detect the locations to perform our SCA scan (i.e., part of the audit command).

Currently, after processing these issues, the Descriptors information is not available and is not included in the results. Consequently, Frogbot assumes it only needs to fix issues in one repository (the root) since it lacks the detected information.

To work around this issue as a short-term solution, you can use our Frogbot configuration and define four working directories for the relative folders you see in the logs you shared. This way, Frogbot will also have this information available, and it should not fail while creating the fixes.

Please feel free to let us know if any other issues arise or if you have further questions regarding this matter. Thank you.

[eranturgeman]

Hello @lukaspj
Did @attiasas suggestion helped fixing your issue? Can I close this ticket?