fix: Location in SBOM field shows local filepath instead of location in binary

[jananir640]

Description

It seems that sometimes when cve-bin-tool detects the location/filepath of a dependency, it provides the path where that dependency is locally installed in the environment rather than where the dependency exists on the binary it is scanning. To my understanding, the location field is meant to help users understand where to go to patch, but the existing logic does not necessarily provide that. I see that this issue #3815 added this enhancement, so I am also wondering if this was the intended use.

To reproduce

Steps to reproduce the behaviour:

1. scan using these flags/this config --sbom-output sbom_out.json --sbom-type cyclonedx --sbom-format json
2. on this file https://s3.amazonaws.com/ddagent-windows-stable/ddagent-cli-7.55.2.msi
3. then view the context of sbom_out.json

Expected behaviour: the location of openssl on the binary
Actual behaviour: the SBOM shows that the location of openssl is /usr/bin/openssl whereas this is not a valid path on the binary, but rather is the path where openssl is locally installed

Version/platform info

Version of CVE-bin-tool( e.g. output of cve-bin-tool --version): v3.3.1dev0
Installed from GitHub
Operating system: Linux
Python version (e.g. python3 --version): 3.18.17

Anything else?

Feel free to add any other context here.

[anthonyharrison]

Thanks. I think this is a issue.

The location of the file is based on known locations of key binaries. These known locations are for a Linux based system only. . This is why /usr/bin/openssl is reported; the location has been assumed to be the location on the scanning machine.

If the binary is a Windows executable (which I assume it is), the reported location should probably be a Windows path (or not reported if scanning a Windows binary on a Linux machine)

I can't get the sample msi file to scan on my Linux system (it fails to extract) so I can't see the generated SBOM.

cc @terriko @mastersans

[terriko]

Yeah, I'm not sure why it's doing it that way now that I'm looking at this again. I would have expected it to report the filename where the issue was found, and if that file is an archive ideally we'd report the path within that archive. Probably my bad for approving it.

I guess the good news is that probably we can just replace find_product_location() with something that does the right thing?

[anthonyharrison]

The evidence should be the file which has been scanned. So we should report the archive/executable which has been scanned which contains the component which is being reported.

[terriko]

Re-opening because #4769 fixes this in version_scanner, but does not fix it in sbom_manager. We still need to remove the find_product_location function from util.py (yes, remove it entirely, it's a bad function) and fix sbom_manager/parse.py before this will be completely fixed.

[terriko]

Okay, I think we've fixed this now. There may be room for more fine tuning like telling people what line of an sbom has the relevant component, but at least we're no longer reporting an incorrect location.