SARIF report import - unable to see source context?

[Mikaciu (Mikaël Hautin)]

Hello,

I’m using the Azure Pipelines to generate SARIF logs coming from three different tools : checkov, gitleaks and trivy. CodeAnalysisLogs.zip (4.4 KB)

Then, I import them using the sonar.sarifReportPaths property :
import_sarif_test.log (231.8 KB) ← please note this is a test run, where I import a single SARIF report, for debugging purposes.

When I look at my project in the SonarQube instance (running SonarQube Enterprise 10.0.68432), I can’t locate where in my source file the issue happened : the section “Where is the issue” only shows the project and not the file contents :

Can you reproduce this behaviour ? I don’t have it for other external tools report import, like ESLint.

Precision : I tried changing the runs[].results[].locations[].physicalLocation.artifactLocation.uri property to add absolute paths instead of paths relative to the project root, to no avail.

Thanks,

BR

[Colin]

Hey there.

I’m having trouble finding the actual Scanner logs (where the analysis occurs and is pushed to SonarQube) in any of the logs you shared. Can you help me find them, or point me to them?

[Mikaciu (Mikaël Hautin)]

Hello @Colin !

My bad, I posted the first pipeline job which is irrelevant for this issue. There you go:

perform_sonarqube_analysis.zip (194.6 KB)

Thanks,
BR

[Mikaciu (Mikaël Hautin)]

Hey @Colin,

Was the log I provide suitable to you ?

Thanks,
BR

[Colin]

I’ve flagged this for some experts but they haven’t been able to look at it yet. Thanks for your patience!

[antoine.vinot]

Hi @Mikaciu

Thank you for waiting on this.

I could not reproduce it on my side. Are you sure you have the issue for all three tools (checkov, gitleaks and trivy)? The logs you shared and the capture are only about Trivy. Checkov and gitleaks reports look OK and quite simple. However, the Trivy report seems to use an originalUriBaseIds property which SonarQube doesn’t support at the moment.
But still, it should work if you tried with the absolute path, so, not sure that is the issue here.

Another hypothesis could be related to rights. Maybe the user running the scanner doesn’t have reading rights on the files related to the issues. But I would be surprised about it.

[Mikaciu (Mikaël Hautin)]

Hello @antoine.vinot,

Sorry for the long wait !

Here goes for checkov:

Gitleaks shows the same:

[Mikaciu (Mikaël Hautin)]

Ha ! Found out something else.
This behaviour only happens using the MSBuild analyzer, the CLI analyzer does not have the issue.

[Andrei_Epure]

Hi @Mikaciu

@Mikaciu

I’m using the Azure Pipelines to generate SARIF logs coming from three different tools : checkov, gitleaks and trivy.

Would you be able to share with us the configuration / commands that you are using to generate the SARIF reports? Together with the version of the tools that you are using.

Ideally, if you can share a small reproducer project with a configured pipeline, that we could fork and setup and run, it would be grand.

Otherwise, just the commands + exact tool versions will greatly help us reproduce and investigate the problems.

[Mikaciu (Mikaël Hautin)]

Hello @Andrei_Epure,

There you go!

Checkov 2.4.20

checkov --directory . --config-file /etc/anubis/checkov/checkov-config.yml --output sarif --output-file-path $(Build.ArtifactStagingDirectory)/

/etc/anubis/checkov/checkov-config.yml

compact: true
quiet: true
skip-check:
  # Ensure that HEALTHCHECK instructions have been added to container images
  - CKV_DOCKER_2

  # Ensure that the expiration date is set on all secrets
  - CKV_AZURE_41
  # Ensure that managed disks use a specific set of disk encryption sets for the customer-managed key encryption
  - CKV_AZURE_93
  # "Ensure that Cosmos DB accounts have customer-managed keys to encrypt data at rest"
  - CKV_AZURE_100
  # Ensure that Azure Service Bus uses a customer-managed key to encrypt data
  - CKV_AZURE_201

  # "Ensure storage for critical data are encrypted with Customer Managed Key"
  - CKV2_AZURE_1
  # Ensure that Azure Data Explorer encryption at rest uses a customer-managed key
  - CKV2_AZURE_11
  # Ensure that Azure data factories are encrypted with a customer-managed key
  - CKV2_AZURE_15
  # Ensure that MySQL server enables customer-managed key for encryption
  - CKV2_AZURE_16
  # Ensure that PostgreSQL server enables customer-managed key for encryption
  - CKV2_AZURE_17
  # Ensure that Storage Accounts use customer-managed key for encryption
  - CKV2_AZURE_18

gitleaks 8.18.0

report_path="$(Build.ArtifactStagingDirectory)/${{ variables.report_prefix }}_gitleaks.sarif"
gitleaks detect --redact --config /etc/anubis/gitleaks/gitleaks.toml --no-git --report-format sarif --report-path "${report_path}"

/etc/anubis/gitleaks/gitleaks.toml

gitleaks.zip (4.6 KB)

trivy 0.45.0

report_path="$(Build.ArtifactStagingDirectory)/${{ variables.report_prefix }}_trivy.sarif"
trivy fs --scanners config,secret $(Build.SourcesDirectory) --policy /etc/anubis/trivy/policies/ --exit-code 1 --format sarif --output "${report_path}"

/etc/anubis/trivy/policies/no_healthcheck_exception.rego

package builtin.dockerfile.DS026

exception[rules] {
  	rules := [""]
}

[Mikaciu (Mikaël Hautin)]

There you go the the example project:
files.zip (32.0 KB)

[Andrei_Epure]

Hello @Mikaciu

Sorry for making you wait.

I ran the analysis and for the external issues from Trivy on C# code, they are imported as expected, with file contents:

The issues on the python and json files were not loaded because MSBuild doesn’t know about those Python files, so it doesn’t “tell” the Sonar analysis that those python files are on disk.

I’ve written an article on my personal blog about how to “tell” MSBuild about those files in the build pipeline - you can read it here.

I applied the trick in your case and added to “SonarTest\SonarTest\SonarTest.csproj” the following:

  <ItemGroup>
    <None Include="../../python/**" />
    <None Include="*.json" />
    <None Include="../../*.json" />
  </ItemGroup>

And reran the scan and imported the results and now the Python and JSON files are imported correctly for the Trivy and Checkov issues. I wasn’t able to install gitleaks, but I guess it would be similar.

Note: the S4NET (Sonar Scanner for .NET) normally takes as base directory the directory of the solution (SLN) file, so I needed to pass explicitly the base Dir (sonar.projectBaseDir) for the files outside of the solution folder to be imported.

dotnet  SonarScanner.MSBuild.dll begin /k:"mytest"  /d:sonar.login="<TOKEN>" /d:sonar.projectBaseDir="C:\investigations\2023-10-04-sarif\files" /d:sonar.sarifReportPaths=C:\investigations\2023-10-04-sarif\output\results_sarif.sarif,C:\investigations\2023-10-04-sarif\output\trivy.sarif
dotnet build .\SonarTest\SonarTest.sln
dotnet  C:\workspace\sonar-scanner-msbuild\build\sonarscanner-msbuild-netcoreapp2.0\SonarScanner.MSBuild.dll end /d:sonar.login="<TOKEN>"

One remark I have is that now all the issues raised by these external tools are also raised by SonarQube.