-
Notifications
You must be signed in to change notification settings - Fork 210
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
Comments
Just curious, what is the use case where this would be used ? |
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. |
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. |
This makes 100% sense.
So this way we could get both a vulnerabilities lookup by CPE, and purl lookup by CPE |
Reference: #585 * Lookup Vulnerabilities by CPE
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.
The text was updated successfully, but these errors were encountered: