-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: [bug description] Location field for component when scanning a SBOM maybe inaccurate #4676
Labels
enhancement
New feature or request
Comments
I think this is a duplicate of #4396 But yes, definitely needs fixing. |
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 5, 2025
Do not use find_product_location to set the location field in version_scanner.py as otherwise cve-bin-tool will try to find the location of the product on the host system (which is obviously wrong). Instead, set the location to be the file_path relative to the rootdir that was given to cve-bin-tool Fix intel#4396 and intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 5, 2025
Do not use find_product_location to set the location field in version_scanner.py as otherwise cve-bin-tool will try to find the location of the product on the host system (which is obviously wrong). Instead, set the location to be the file_path relative to the rootdir that was given to cve-bin-tool Fix intel#4396 and intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 14, 2025
Drop find_product_location as it tries to find the location of the product on the system parsing the SBOM which obviously doesn't make sense While at it, drop location totally from ProductInfo. Indeed, currently only the first location of the product is saved in the SBOM. Instead of using this location field, set the evidence to be the list of paths saved in all_cve_data. This will avoid to duplicate information. __identity_members, __eq__ and __hash__, which were added by commit f1d3c75 to handle location, are kept to still handle the optional purl parameter and avoid breaking test_product_info_{equality,hashing} tests. Fix intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 14, 2025
Drop find_product_location as it tries to find the location of the product on the system parsing the SBOM which obviously doesn't make sense While at it, drop location totally from ProductInfo. Indeed, currently only the first location of the product is saved in the SBOM. Instead of using this location field, set the evidence to be the list of paths saved in all_cve_data. This will avoid to duplicate information. __identity_members, __eq__ and __hash__, which were added by commit f1d3c75 to handle location, are kept to still handle the optional purl parameter and avoid breaking test_product_info_{equality,hashing} tests. Fix intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 14, 2025
Drop find_product_location as it tries to find the location of the product on the system parsing the SBOM which obviously doesn't make sense While at it, drop location totally from ProductInfo. Indeed, currently only the first location of the product is saved in the SBOM. Instead of using this location field, set the evidence to be the list of paths saved in all_cve_data. This will avoid to duplicate information. __identity_members, __eq__ and __hash__, which were added by commit f1d3c75 to handle location, are kept to still handle the optional purl parameter and avoid breaking test_product_info_{equality,hashing} tests. Fix intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 14, 2025
Drop find_product_location as it tries to find the location of the product on the system parsing the SBOM which obviously doesn't make sense While at it, drop location totally from ProductInfo. Indeed, currently only the first location of the product is saved in the SBOM. Instead of using this location field, set the evidence to be the list of paths saved in all_cve_data. This will avoid to duplicate information. __identity_members, __eq__ and __hash__, which were added by commit f1d3c75 to handle location, are kept to still handle the optional purl parameter and avoid breaking test_product_info_{equality,hashing} tests. Fix intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 14, 2025
Drop find_product_location as it tries to find the location of the product on the system parsing the SBOM which obviously doesn't make sense While at it, drop location totally from ProductInfo. Indeed, currently only the first location of the product is saved in the SBOM. Instead of using this location field, set the evidence to be the list of paths saved in all_cve_data. This will avoid to duplicate information. __identity_members, __eq__ and __hash__, which were added by commit f1d3c75 to handle location, are kept to still handle the optional purl parameter and avoid breaking test_product_info_{equality,hashing} tests. Fix intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 14, 2025
Drop find_product_location as it tries to find the location of the product on the system parsing the SBOM which obviously doesn't make sense While at it, drop location totally from ProductInfo. Indeed, currently only the first location of the product is saved in the SBOM. Instead of using this location field, set the evidence to be the list of paths saved in all_cve_data. This will avoid to duplicate information. __identity_members, __eq__ and __hash__, which were added by commit f1d3c75 to handle location, are kept to still handle the optional purl parameter and avoid breaking test_product_info_{equality,hashing} tests. Fix intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 14, 2025
Drop find_product_location as it tries to find the location of the product on the system parsing the SBOM which obviously doesn't make sense While at it, drop location totally from ProductInfo. Indeed, currently only the first location of the product is saved in the SBOM. Instead of using this location field, set the evidence to be the list of paths saved in all_cve_data. This will avoid to duplicate information. __identity_members, __eq__ and __hash__, which were added by commit f1d3c75 to handle location, are kept to still handle the optional purl parameter and avoid breaking test_product_info_{equality,hashing} tests. Fix intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
ffontaine
added a commit
to ffontaine/cve-bin-tool
that referenced
this issue
Feb 14, 2025
Drop find_product_location as it tries to find the location of the product on the system parsing the SBOM which obviously doesn't make sense While at it, drop location totally from ProductInfo. Indeed, currently only the first location of the product is saved in the SBOM. Instead of using this location field, set the evidence to be the list of paths saved in all_cve_data. This will avoid to duplicate information. __identity_members, __eq__ and __hash__, which were added by commit f1d3c75 to handle location, are kept to still handle the optional purl parameter and avoid breaking test_product_info_{equality,hashing} tests. Fix intel#4676 Signed-off-by: Fabrice Fontaine <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
The value of the location field in the JSON report is the location of the component on the local system. When scanning an SBOM, it is unlikely that the product referenced in the SBOM will be installed on the system where cve-bin-tool is being run. The location of the component MAY be included in the SBOM (CycloneDX has an evidence attribute which can include the file path of the component) but it is highly unlikely to be the same as is installed on the system being used.
Why?
The approach followed gives misleading results. For instance, scanning a SBOM for an application deployed using Python 3.9 produces locations for the components installed on the current system(a Python 3.10).
Anything else?
Suggest populating the location is made optional for SBOMs (with a default of False)
The text was updated successfully, but these errors were encountered: