fix(sarif): handle empty `artifactLocation.uri` fields

[nikpivkin]

Related Issues:

• https://github.com/aquasecurity/trivy-action/issues/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:

• https://github.com/github/codeql-action/issues/2456
• https://github.com/microsoft/sarif-sdk/issues/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 https://github.com/microsoft/sarif-sdk/issues/2770#issuecomment-2305910157)

[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.

UPD: Created #8189 for this case

[ZsoltPath]

This issue came back for me today with Trivy v0.65 and v0.67 as well.

[DmitriyLewen]

Hello @ZsoltPath Can you share some example for this?

[crivetechie]

We're run into the same issue since yesterday (07 Oct 2025).

The issue is occurring with versions v0.65.0 to v0.67.0. The issue is not present in v0.64.1

Versions from v0.65.0 to v0.67.0 are finding multiple matches for the rule storage-bucket-versioning-disabled https://avd.aquasec.com/misconfig/google/storage/avd-gcp-0078/ but one of these contain empty artifactLocation.uri

{
          "ruleId": "storage-bucket-versioning-disabled",
          "ruleIndex": 0,
          "level": "warning",
          "message": {
            "text": "Artifact: \nType: terraform\nVulnerability storage-bucket-versioning-disabled\nSeverity: MEDIUM\nMessage: Storage bucket versioning is not enabled.\nLink: [storage-bucket-versioning-disabled](https://avd.aquasec.com/misconfig/storage-bucket-versioning-disabled)"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "",
                  "uriBaseId": "ROOTPATH"
                },
                "region": {
                  "startLine": 1,
                  "startColumn": 1,
                  "endLine": 1,
                  "endColumn": 1
                }
              },
              "message": {
                "text": ""
              }
            }
          ]
        }

we've encountered a similar issue on another repository with rule AVD-AZU-0012

 {
          "ruleId": "AVD-AZU-0012",
          "ruleIndex": 0,
          "level": "error",
          "message": {
            "text": "Artifact: \nType: terraform\nVulnerability AVD-AZU-0012\nSeverity: CRITICAL\nMessage: No network rules defined and default action allows access.\nLink: [AVD-AZU-0012](https://avd.aquasec.com/misconfig/avd-azu-0012)"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "",
                  "uriBaseId": "ROOTPATH"
                },
                "region": {
                  "startLine": 1,
                  "startColumn": 1,
                  "endLine": 1,
                  "endColumn": 1
                }
              },
              "message": {
                "text": ""
              }
            }
          ]
        }

[DmitriyLewen]

@nikpivkin Can you take a look? IIUC target with this misconfig is empty. Is this possible?

[crivetechie]

I just wanted to inform you that the issue isn't happening anymore. I've tested against the configuration of my first example and there are no hits for storage-bucket-versioning-disabled rule