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

Extend the API to allow queries by CPE #585

Closed
sschuberth opened this issue Dec 15, 2021 · 5 comments · Fixed by #667
Closed

Extend the API to allow queries by CPE #585

sschuberth opened this issue Dec 15, 2021 · 5 comments · Fixed by #667

Comments

@sschuberth
Copy link

As discussed as part of the PURL spec, we cannot have a generic CPE <-> PURL mapping and need to track CPEs separately for the time being. Which also means to me that we should allow VulnerableCode to be queried by CPE directly, in addition to the supported queries by PURL.

@sbs2001
Copy link
Collaborator

sbs2001 commented Dec 17, 2021

Just curious, what is the use case where this would be used ?

@sschuberth
Copy link
Author

Well, the use-case is e.g. C/C++ projects that do not use a package manager but build via Makefiles from source. Third-party libraries, like OpenSSL for example, that are part of the source tree then cannot have a meaningful PURL: What would be the PURL's type?

But you might have a CPE for the version of OpenSSL (in this example) you're building from source, and you'd want to use that to look up any known vulnerabilities in OpenSSL.

Or phrased differently: Most of the time vulnerabilities have their cause in the source code, not in the packaging. Thus, no matter how you package OpenSSL 1.0.1, it's still affected by the Heartbleed vulnerability (unless you apply custom patching as part of the packaging). This means we need a way to lookup vulnerabilities independently of the packaging, so PURLs are not suitable as they are Package URLs. CPEs on the other hand would work here.

@jbmaillet
Copy link

Example use case: the entire industries of embedded / IoT: no packaging, everything built from sources.

Some embedded build systems such as Yocto used by AGL for instance can produce RPM/DEB as output, but even in this case they are built from the upstream sources from scratch, independently of any existing distribution such as Debian, Ubuntu, Feroda etc.

@pombredanne
Copy link
Member

This makes 100% sense.
The resolution is going to include likely:

  1. enable lookup by CPE
  2. ensure that we also include the CPE in all the Package references in the DB when this is available
  3. these in turn can be used to publish a reference and continusously updated purl <-> CPE mapping using https://github.com/nexB/vulnerablecode/blob/main/vulnerabilities/management/commands/create_cpe_to_purl_map.py
    You can see an example at by @sbs2001 https://github.com/sbs2001/purl2cpe

So this way we could get both a vulnerabilities lookup by CPE, and purl lookup by CPE

@pombredanne
Copy link
Member

@TG1999 Do you think you could have a look into this? It feels like a natural follow up from the #666 NVD importer migration

@TG1999 TG1999 linked a pull request Apr 26, 2022 that will close this issue
TG1999 added a commit that referenced this issue Apr 26, 2022
Reference: #585

* Lookup Vulnerabilities by CPE
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants