fix(sarif): handle empty artifactLocation.uri fields

[nikpivkin]

Related Issues:

• Issue with uploading the SARIF report to GitHub trivy-action#408

In some cases, Trivy generates a SARIF report with an empty artifactLocation.uri. Although such reports successfully pass validation at https://sarifweb.azurewebsites.net/Validation, which is recommended by GitHub in their documentation, uploading them using the github/codeql-action/upload-sarif action fails with the following error:

Error: Code Scanning could not process the submitted SARIF file:
locationFromSarifResult: expected artifact location, locationFromSarifResult: expected artifact location

This remains an unresolved issue:

• Error while uploading SARIF file using action github/codeql-action/upload-sarif github/codeql-action#2456
• Valid SARIF file being rejected by GitHub with locationFromSarifResult error microsoft/sarif-sdk#2770

Potential solutions:

1. Remove results that do not meet the criteria from the report and log this.
2. As suggested in a discussion, populate the artifactLocation.uri field with a dummy value.

[nikpivkin]

@aquasecurity/trivy WDYT?

[DmitriyLewen]

Correct me if I'm wrong:
We use Target field for secrets and licenses.
We also use Target or PkgPath for vulnerabilities.
So for them artifactLocation.uri is always non-empty.

This means we have to handle cases with misconfigs.
We can use modules (like terraform) for artifactLocation.uri (#7897)
And IIUC these modules can be empty.
Can we use the name of the file being scanned (e.g. main.tf) in this case?

[nikpivkin]

The whole problem is that Target can be empty, so we can't fill in artifactLocation.uri. Users have encountered this when scanning images for vulnerabilities (see microsoft/sarif-sdk#2770 (comment))

[DmitriyLewen]

thanks. I missed this comment.

I found the reason for empty Target.
It happens for SBOM files not generated by Trivy (when we can't determine filepath for Application).
But I think we need to fix this issue for Trivy - each result should contain Target.

I added logic to add filepath for aggregated languages ​​- #8052

But it seems that we always need to add filepath if we can't determine it (no matter what the reason).
But there is one problem with this:
We can show Application path or SBOM filepath - this can confuse users.