Skip to content
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

Clearly document the fact that CPE strings could be made up #2800

Open
prabhu opened this issue Apr 22, 2024 · 1 comment
Open

Clearly document the fact that CPE strings could be made up #2800

prabhu opened this issue Apr 22, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@prabhu
Copy link

prabhu commented Apr 22, 2024

What would you like to be added:
Upon reviewing the code, it is clear that the tool is simply making up CPEs as it goes when there is no hit on the cpe-index.json file.

A search on issues for "wrong cpe" or "incorrect package name" shows additional reports across ecosystems.

Why is this needed:

The information about CPE correctness is not clearly communicated to the end user. Many tools, including the official NTIA benchmark tools, are treating these values as correct without enough validation.

Where the confidence of a given identity is low, it must be represented in the resulting SBOM. For example, in CycloneDX use component.evidence.identity with field cpe, appropriate methods.technique and confidence. For SPDX, which lacks support for evidence, an alternative solution may need to be found.

In the long term, consider adopting PURL which has an higher precision and is often easier to construct, compared to CPEs, for multiple ecosystems.

Additional context:

@prabhu prabhu added the enhancement New feature or request label Apr 22, 2024
@tgerla
Copy link
Contributor

tgerla commented May 2, 2024

Hi @prabhu, thanks for the report. We are definitely familiar with the shortcomings of CPE generation and CPE matching and we're interested in including some kind of confidence score when we generate a CPE not found in the index. We have some work to do figuring out the method for scoring.

If you haven't already, please take a look at an SBOM generated in syft-json format. You will see all of the source of the CPEs we generated or were declared, as well as the PURLs for the artifacts found by the Syft scan.

This sounds like a good topic for our community meeting if you are interested in discussing it with the team live -- feel free to join the next one if you like! https://github.com/anchore/syft/?tab=readme-ov-file#join-our-community-meetings

We'll move this issue into backlog but we definitely need to do some more design work before we can implement any solutions. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Backlog
Development

No branches or pull requests

2 participants