Sarif files cannot be seen in azure devops scan tab or sonarqube v0.37.1

[rubencc]

Description

Sarif files cannot be seen in azure devops scan tab nor new issues appear in sonarqube

What did you expect to happen?

1 - That the resulting artifact with the sarif files can be shown in the scan tab of the azure devops build 2 - That when importing the sarif file in sonarqube the detected vulnerabilities are shown

What happened instead?

1 - Although the scan tab detects the artifact and it contains the sarif files generated, the results are not seen 2 - SonarQube imports and detects the vulnerabilities in the file but they are not shown in the report

Output of run with -debug:

(paste your output here)

Output of trivy -v:

v 0.37.1

Additional details (base image name, container registry info...):

We are using the trivy cli from https://github.com/aquasecurity/trivy/releases/download/v0.37.1/trivy_0.37.1_Linux-64bit.deb

AzureDevOps Task

  # Scan Low and Medium risks (no error if exists any)
  - task: Bash@3
    displayName: ${{ parameters.displayName }} (LOW and MEDIUM risks)
    inputs:
      targetType: 'inline'      
      script: trivy fs -f sarif --severity LOW,MEDIUM --skip-dirs "${{ parameters.excludedFolder }}" --vuln-type library --ignore-unfixed --exit-code 0 -o $(Agent.TempDirectory)/trivy_low.sarif ${{ parameters.folder }}

Sarif result file

{
  "version": "2.1.0",
  "$schema": "https://json.schemastore.org/sarif-2.1.0-rtm.5.json",
  "runs": [
    {
      "tool": {
        "driver": {
          "fullName": "Trivy Vulnerability Scanner",
          "informationUri": "https://github.com/aquasecurity/trivy",
          "name": "Trivy",
          "rules": [
            {
              "id": "GHSA-qrmm-w75w-3wpx",
              "name": "LanguageSpecificPackageVulnerability",
              "shortDescription": {
                "text": "Server side request forgery in SwaggerUI"
              },
              "fullDescription": {
                "text": "SwaggerUI supports displaying remote OpenAPI definitions through the `?url` parameter. This enables robust demonstration capabilities on sites like `petstore.swagger.io`, `editor.swagger.io`, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.\n\nHowever, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.\n\nAn example scenario abusing this functionality could take the following form:\n- `https://example.com/api-docs` hosts a version of SwaggerUI with `?url=` query parameter enabled.\n- Users will trust the domain `https://example.com` and the contents of the OpenAPI definition.\n- A malicious actor may craft a similar OpenAPI definition and service that responds to the defined APIs at `https://evildomain`.\n- Users mistakenly click a phishing URL like `https://example.com/api-docs?url=https://evildomain/fakeapi.yaml` and enters sensitive data via the \u0026#34;Try-it-out\u0026#34; feature.\n\nWe do want to stress that this attack vector is limited to scenarios that actively trick users into divulging sensitive information. The ease of this is highly contextual and, therefore, the threat model may be different for individual users and organizations. It is *not* possible to perform non-interactive attacks (e.g., cross-site scripting or code injection) through this mechanism.\n\n### Resolution \nWe\u0026#39;ve made the decision to [disable query parameters (#4872)](https://github.com/swagger-api/swagger-ui/issues/4872) by default starting with SwaggerUI version `4.1.3`. Please update to this version when it becomes available (**ETA: 2021 December**). Users will still be able to be re-enable the options at their discretion. We\u0026#39;ll continue to enable query parameters on the Swagger demo sites.\n\n### Workaround\nIf you host a version of SwaggerUI and wish to mitigate this issue immediately, you are encouraged to add the following custom plugin code:\n\n```js\nSwaggerUI({\n  //  ...other configuration options,\n  plugins: [function UrlParamDisablePlugin() {\n    return {\n      statePlugins: {\n        spec: {\n          wrapActions: {\n            // Remove the ?url parameter from loading an external OpenAPI definition.\n            updateUrl: (oriAction) =\u0026gt; (payload) =\u0026gt; {\n              const url = new URL(window.location.href)\n              if (url.searchParams.has(\u0026#39;url\u0026#39;)) {\n                url.searchParams.delete(\u0026#39;url\u0026#39;)\n                window.location.replace(url.toString())\n              }\n              return oriAction(payload)\n            }\n          }\n        }\n      }\n    }\n  }],\n})\n```\n\n### Future UX work\n\nThrough the exploration of this issue, it became apparent that users may not be aware to which web server the Try-it-out function will send requests. While this information is currently presented at the top of the page, understanding may improve by displaying it closer to the \u0026#34;Execute\u0026#34; button where requests are actually made. We\u0026#39;ll be exploring these UX improvements over the coming months and welcome community input. Please create a Feature Request under the GitHub Issue tab to start a conversation with us and the community.\n\n## Reflected XSS attack\n\n**Warning** in versions \u0026lt; 3.38.0, it is possible to combine the URL options (as mentioned above) with a vulnerability in DOMPurify (https://www.cvedetails.com/cve/CVE-2020-26870/) to create a reflected XSS vector. If your version of Swagger UI is older than 3.38.0, we suggest you upgrade or implement the workaround as mentioned above.\n"
              },
              "defaultConfiguration": {
                "level": "warning"
              },
              "helpUri": "https://github.com/advisories/GHSA-qrmm-w75w-3wpx",
              "help": {
                "text": "Vulnerability GHSA-qrmm-w75w-3wpx\nSeverity: MEDIUM\nPackage: Swashbuckle.AspNetCore.SwaggerUI\nFixed Version: 6.4\nLink: [GHSA-qrmm-w75w-3wpx](https://github.com/advisories/GHSA-qrmm-w75w-3wpx)\nSwaggerUI supports displaying remote OpenAPI definitions through the `?url` parameter. This enables robust demonstration capabilities on sites like `petstore.swagger.io`, `editor.swagger.io`, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.\n\nHowever, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.\n\nAn example scenario abusing this functionality could take the following form:\n- `https://example.com/api-docs` hosts a version of SwaggerUI with `?url=` query parameter enabled.\n- Users will trust the domain `https://example.com` and the contents of the OpenAPI definition.\n- A malicious actor may craft a similar OpenAPI definition and service that responds to the defined APIs at `https://evildomain`.\n- Users mistakenly click a phishing URL like `https://example.com/api-docs?url=https://evildomain/fakeapi.yaml` and enters sensitive data via the \"Try-it-out\" feature.\n\nWe do want to stress that this attack vector is limited to scenarios that actively trick users into divulging sensitive information. The ease of this is highly contextual and, therefore, the threat model may be different for individual users and organizations. It is *not* possible to perform non-interactive attacks (e.g., cross-site scripting or code injection) through this mechanism.\n\n### Resolution \nWe've made the decision to [disable query parameters (#4872)](https://github.com/swagger-api/swagger-ui/issues/4872) by default starting with SwaggerUI version `4.1.3`. Please update to this version when it becomes available (**ETA: 2021 December**). Users will still be able to be re-enable the options at their discretion. We'll continue to enable query parameters on the Swagger demo sites.\n\n### Workaround\nIf you host a version of SwaggerUI and wish to mitigate this issue immediately, you are encouraged to add the following custom plugin code:\n\n```js\nSwaggerUI({\n  //  ...other configuration options,\n  plugins: [function UrlParamDisablePlugin() {\n    return {\n      statePlugins: {\n        spec: {\n          wrapActions: {\n            // Remove the ?url parameter from loading an external OpenAPI definition.\n            updateUrl: (oriAction) =\u003e (payload) =\u003e {\n              const url = new URL(window.location.href)\n              if (url.searchParams.has('url')) {\n                url.searchParams.delete('url')\n                window.location.replace(url.toString())\n              }\n              return oriAction(payload)\n            }\n          }\n        }\n      }\n    }\n  }],\n})\n```\n\n### Future UX work\n\nThrough the exploration of this issue, it became apparent that users may not be aware to which web server the Try-it-out function will send requests. While this information is currently presented at the top of the page, understanding may improve by displaying it closer to the \"Execute\" button where requests are actually made. We'll be exploring these UX improvements over the coming months and welcome community input. Please create a Feature Request under the GitHub Issue tab to start a conversation with us and the community.\n\n## Reflected XSS attack\n\n**Warning** in versions \u003c 3.38.0, it is possible to combine the URL options (as mentioned above) with a vulnerability in DOMPurify (https://www.cvedetails.com/cve/CVE-2020-26870/) to create a reflected XSS vector. If your version of Swagger UI is older than 3.38.0, we suggest you upgrade or implement the workaround as mentioned above.\n",
                "markdown": "**Vulnerability GHSA-qrmm-w75w-3wpx**\n| Severity | Package | Fixed Version | Link |\n| --- | --- | --- | --- |\n|MEDIUM|Swashbuckle.AspNetCore.SwaggerUI|6.4|[GHSA-qrmm-w75w-3wpx](https://github.com/advisories/GHSA-qrmm-w75w-3wpx)|\n\nSwaggerUI supports displaying remote OpenAPI definitions through the `?url` parameter. This enables robust demonstration capabilities on sites like `petstore.swagger.io`, `editor.swagger.io`, and similar sites, where users often want to see what their OpenAPI definitions would look like rendered.\n\nHowever, this functionality may pose a risk for users who host their own SwaggerUI instances. In particular, including remote OpenAPI definitions opens a vector for phishing attacks by abusing the trusted names/domains of self-hosted instances.\n\nAn example scenario abusing this functionality could take the following form:\n- `https://example.com/api-docs` hosts a version of SwaggerUI with `?url=` query parameter enabled.\n- Users will trust the domain `https://example.com` and the contents of the OpenAPI definition.\n- A malicious actor may craft a similar OpenAPI definition and service that responds to the defined APIs at `https://evildomain`.\n- Users mistakenly click a phishing URL like `https://example.com/api-docs?url=https://evildomain/fakeapi.yaml` and enters sensitive data via the \"Try-it-out\" feature.\n\nWe do want to stress that this attack vector is limited to scenarios that actively trick users into divulging sensitive information. The ease of this is highly contextual and, therefore, the threat model may be different for individual users and organizations. It is *not* possible to perform non-interactive attacks (e.g., cross-site scripting or code injection) through this mechanism.\n\n### Resolution \nWe've made the decision to [disable query parameters (#4872)](https://github.com/swagger-api/swagger-ui/issues/4872) by default starting with SwaggerUI version `4.1.3`. Please update to this version when it becomes available (**ETA: 2021 December**). Users will still be able to be re-enable the options at their discretion. We'll continue to enable query parameters on the Swagger demo sites.\n\n### Workaround\nIf you host a version of SwaggerUI and wish to mitigate this issue immediately, you are encouraged to add the following custom plugin code:\n\n```js\nSwaggerUI({\n  //  ...other configuration options,\n  plugins: [function UrlParamDisablePlugin() {\n    return {\n      statePlugins: {\n        spec: {\n          wrapActions: {\n            // Remove the ?url parameter from loading an external OpenAPI definition.\n            updateUrl: (oriAction) =\u003e (payload) =\u003e {\n              const url = new URL(window.location.href)\n              if (url.searchParams.has('url')) {\n                url.searchParams.delete('url')\n                window.location.replace(url.toString())\n              }\n              return oriAction(payload)\n            }\n          }\n        }\n      }\n    }\n  }],\n})\n```\n\n### Future UX work\n\nThrough the exploration of this issue, it became apparent that users may not be aware to which web server the Try-it-out function will send requests. While this information is currently presented at the top of the page, understanding may improve by displaying it closer to the \"Execute\" button where requests are actually made. We'll be exploring these UX improvements over the coming months and welcome community input. Please create a Feature Request under the GitHub Issue tab to start a conversation with us and the community.\n\n## Reflected XSS attack\n\n**Warning** in versions \u003c 3.38.0, it is possible to combine the URL options (as mentioned above) with a vulnerability in DOMPurify (https://www.cvedetails.com/cve/CVE-2020-26870/) to create a reflected XSS vector. If your version of Swagger UI is older than 3.38.0, we suggest you upgrade or implement the workaround as mentioned above.\n"
              },
              "properties": {
                "precision": "very-high",
                "security-severity": "5.5",
                "tags": [
                  "vulnerability",
                  "security",
                  "MEDIUM"
                ]
              }
            }
          ],
          "version": "0.37.1"
        }
      },
      "results": [
        {
          "ruleId": "GHSA-qrmm-w75w-3wpx",
          "ruleIndex": 0,
          "level": "warning",
          "message": {
            "text": "Package: Swashbuckle.AspNetCore.SwaggerUI\nInstalled Version: 6.2.3\nVulnerability GHSA-qrmm-w75w-3wpx\nSeverity: MEDIUM\nFixed Version: 6.4\nLink: [GHSA-qrmm-w75w-3wpx](https://github.com/advisories/GHSA-qrmm-w75w-3wpx)"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "TASuite.MUC.Service/bin/Release/net6.0/TASuite.MUC.Service.deps.json",
                  "uriBaseId": "ROOTPATH"
                },
                "region": {
                  "startLine": 2620,
                  "startColumn": 1,
                  "endLine": 2626,
                  "endColumn": 1
                }
              },
              "message": {
                "text": "TASuite.MUC.Service/bin/Release/net6.0/TASuite.MUC.Service.deps.json: [email protected]"
              }
            }
          ]
        }
      ],
      "columnKind": "utf16CodeUnits",
      "originalUriBaseIds": {
        "ROOTPATH": {
          "uri": "file:///"
        }
      }
    }
  ]
}

[rubencc]

It seen to be related with a bug in sonarqube that will fix in v9.9. https://community.sonarsource.com/t/trouble-importing-sarif-reports/79309/10

Some one coule confirm it?

[dlinares-linux]

Hi @rubencc I have experienced a similar issue with Trivy SARIF reports not displayed in Azure DevOps. In my case, it was not an issue with Trivy but an issue somewhere else (SARIF SAST Scans Tab extension probably) which is not able to display artifacts uploaded with the PublishPipelineArtifact@1 task.

Uploading the artifact with the PublishBuildArtifacts@1 task worked fine. I am using Trivy 0.39.0 and SARIF SAST Scans Tab 0.3.6

  - task: PublishBuildArtifacts@1
    displayName: Publish Trivy SARIF Artifact
    inputs:
      pathToPublish: $(Build.ArtifactStagingDirectory)
      artifactName: CodeAnalysisLogs