Description
What happened:
Here are examples of a NVD entry with a CPE which I guess not match what syft produces
https://nvd.nist.gov/vuln/detail/CVE-2023-39951 uses cpe:2.3:a:linuxfoundation:opentelemetry_instrumentation_for_java:*:*:*:*:*:*:*:*
This is in https://github.com/open-telemetry/opentelemetry-java-instrumentation
https://nvd.nist.gov/vuln/detail/CVE-2023-25151 uses cpe:2.3:a:linuxfoundation:opentelemetry-go_contrib:0.38.0:*:*:*:*:opentelemetry-go:*:*
This is in https://github.com/open-telemetry/opentelemetry-go-contrib
However, https://nvd.nist.gov/vuln/detail/CVE-2023-43810 uses cpe:2.3:a:opentelemetry:opentelemetry:*:*:*:*:*:*:*:*
This is https://github.com/open-telemetry/opentelemetry-python-contrib
I assume the vendor should be linuxfoundation
instead of opentelemetry
for all of these, and syft should be emitting that.
Note I have not seen SBOMs from syft with those CPEs, but in my Rust project I see CPE cpe:2.3:a:opentelemetry:opentelemetry:0.23.0:*:*:*:*:*:*:*
which happens to match https://nvd.nist.gov/vuln/detail/CVE-2023-43810 , and that led me down this garden path.
What you expected to happen:
If I understand correctly, entries are needed in https://github.com/anchore/syft/blob/main/syft/pkg/cataloger/internal/cpegenerate/dictionary/data/cpe-index.json to fix the vendor & product for the various opentelemetry implementations in each language.
I expect that syft provides CPEs that match those used by NVD for CVE-2023-25151 & CVE-2023-39951 and similar.
I expect that syft would generate a CPE that matches CVE-2023-43810 , but also another CPE which uses the appropriate vendor linuxfoundation
I expect for Rust opentelemetry crates, the vendor is linuxfoundation
and the product is the crate name.
Steps to reproduce the issue:
Anything else we need to know?:
Environment:
- Output of
syft version
: - OS (e.g:
cat /etc/os-release
or similar):
Metadata
Metadata
Assignees
Labels
Type
Projects
Status