JSON output file in SonarQube format

[joserenatosilva]

Closes #370

---

This PR aims to enable the huskyCI-client to create a JSON output file compatible with Sonarqube generic issue importation. As it is, every execution creates/overwrites a json file named result.json inside a folder huskyCI created in the current working directory.

[mdjunior]

Hey @joserenatosilva,

This PR is a great contribution, but could you add some tests for the new functions (generateSonarOutput)?
Could the outputs be a separate package? This may facilitate testing and add new possibilities in the future.

Could you add a wiki page explaining how this integration can be done?

[joserenatosilva]

@mdjunior Sure, I'll change the PR to WIP, refactor and create some tests.
To integrate I followed the documentation found here. I didn't test it directly with Sonarqube since our output maps every required field but I'll do it to create a wiki page on how to integrate with Sonarqube.

[joserenatosilva]

@mdjunior the wiki page still missing, but I updated the CLI client (added spotbugs, gitleaks and sonarqube integration).
I merged the master branch here (to update the security tests - spotbugs and gitleaks) so the number of files to review grew too much. I'll list here the files you need to check/review (files that I changed):

CLI Update

cli/client/print.go
cli/cmd/run.go

SonarQube Update

client/cmd/main.go
client/util/*
client/testdata/*
client/integration/sonarqube/*

I'll test the SonarQube integration manually and report back.

[joserenatosilva]

It looks like SonarQube always needs an existing file and a valid line number, how do we approach our low vulnerability indicating that no requirements.txt, yarn.lock or package.json file is missing? Create an empty file and point line 1? I need to fix that, so I'll move back to WIP

[joserenatosilva]

As it is now the client creates a file named sonarqube.json inside a folder named ./huskyCI/ (this is hardcoded inside client/cmd/main.go).

Regarding my last commentary:

It looks like SonarQube always needs an existing file and a valid line number, how do we approach our low vulnerability indicating that no requirements.txt, yarn.lock or package.json file is missing? Create an empty file and point line 1? I need to fix that, so I'll move back to WIP

There are more problems with missing files, in case of vulnerable dependencies, the security tools don't report an associated file and its line (requirements.txt, yarn.lock, package-lock.json, etc.). Aiming to solve all of the missing files cases I created a check that verifies if there's no file associated with a given vulnerability and creates a placeholder file with content:

Placeholder file indicating that no file was associated with this vulnerability.
This usually means that the vulnerability is related to a missing file
or is not associated with any specific file, i.e.: vulnerable dependency versions.

The SonarQube integration won't work correctly locally with our generated .env file. The file being generated right now looks like:

export HUSKYCI_CLIENT_REPO_URL="https://github.com/globocom/huskyCI.git"
export HUSKYCI_CLIENT_REPO_BRANCH="vulns-Golang"
export HUSKYCI_CLIENT_API_ADDR="http://localhost:8888"
export HUSKYCI_CLIENT_API_USE_HTTPS="false"
export HUSKYCI_CLIENT_TOKEN="HUSKYCITOKEN"

As we execute the sonar-scanner with: sonar-scanner -Dsonar.projectKey=$PROJECT_KEY -Dsonar.sources=. -Dsonar.host.url=$SONAR_URL -Dsonar.login=$SONAR_TOKEN -Dsonar.externalIssuesReportPaths=./huskyCI/sonarqube.json, as is specified in sonar.sources=., SonarQube looks for files in the current working directory but since we can specify a different HUSKYCI_CLIENT_REPO_BRANCH from the source code in the working directory or even a completely different HUSKYCI_CLIENT_REPO_URL the command line won't work.

It should work in a CI context since the container should have the current code/branch inside the pipeline. @mdjunior, @rafaveira3 How should we approach this local SonarQube execution?

[rafaveira3]

Hey, @joserenatosilva! This is a great contribution! 🚀 Thanks a lot for your time and effort in working on this one. As we do not use Sonar in our local environment (via docker-compose, for example), we can think about this in another moment. It would be great if we focus on the CI context. 🙃

[rafaveira3]

Thanks for the pair review, @joserenatosilva! Sounds good to me! Let's test this integration in DEV and check for any bugs found.🚀