Less Fields under SonarQube Vulnerabilities compared to Fields in Imported .sarif

Hi,

I am trying to integrate SonarQube ( v9.9.7 LTS) with Jfrog Xray for dependency scanning instead of using the SonarQube dependency scan plugin. In the pipeline, I used below commands & able to import .sarif to SonarQube. I am able to see them under vulnerabilities with less details(fields) compared to .sarif & I want to include runs[].results[].properties.fixedVersion . How can I achieve this?

jf audit --format=sarif --url="${ARTIFACTORY_URL}/xray" --user=${ARTIFACTORY_USERNAME} --password=${ARTIFACTORY_PASSWORD} > target/dependency-check-report.sarif

sonar.sarifReportPaths=target/dependency-check-report.sarif

Sample result in .sarif file:

“version”: “2.1.0”
“$schema”: “https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json”

        {
          "properties": {
            "fixedVersion": "[2.14.0]"
          },
          "ruleId": "CVE-2024-47554_commons-io:commons-io_2.11.0",
          "ruleIndex": 38,
          "level": "error",
          "message": {
            "text": "[CVE-2024-47554] commons-io:commons-io 2.11.0"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "pom.xml"
                }
              }
            }
          ]
        }

Screenshot of particular vulnerability in Sonarqube:

Thank you.

@ganncamp I mentioned you, because I saw you have supported many sarif related queries. Is there any possibility to support runs[].results[].properties.fixedVersion field on newer SonarQube LTS versions, as it will help integrating Jfrog Xray with SonarQube for dependency scanning without using SonarQube dependancy scanning plugin?

Otherwise it needs to use a separate script to update the generated .sarif file (by concatenating the value in runs[].results[].properties.fixedVersion to supported field like runs[].results[].ruleId).

Hey @Dilshan_Peiris

Please don’t tag individuals in threads who are not already involved in the thread. You may think it bumps it to the top of their list, but actually, it does the exact opposite!

It’s not possible to modify the issue message or pass more details to SonarQube. If I understand it correctly, just about any property name can be put under properties, and we aren’t specifically integrating with JFrog XRay. Today, we don’t offer any functionality to enrich issues with extra data from the SARIF file.

That said, I think it’s an interesting request and is also relevant with regard to some other work we’re doing around dependencies. I’ll flag this for attention from the right PM.

Hello,

The SARIF importer did not receive much love these past months. Still, we made some improvements by supporting the loading of the rules section. I think you should give it a try using the SonarQube Server 10.7 and see if that improves your experience a little.

We are planning to do some improvements to enhance the SARIF Importer:

  • Users can fine-tune Issue Type (Code Smells, Bugs, Vuln) or Software Quality and Severity of SARIF’s findings
  • SonarQube better supports SARIF files containing CVE findings

Each SCA provider populates the SARIF content as they want; there is no standard. This means that it’s not possible to have a nice generic SARIF importer because the information we need must be found in different generic fields, such as “properties,” for each vendor.
In order to implement “SonarQube better supports SARIF files containing CVE findings,” we will need to get access to some examples of SARIF output generated by SCA vendors. This is where you could help.

Could you generate a Jfrog Xray SARIF output of this project and share it with me privately?

Thanks
Alex

1 Like