-
Notifications
You must be signed in to change notification settings - Fork 587
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Show richer information for JVM installations #1426
Comments
How do you expect to see this information in the SBOM? There aren't places in all SBOM formats (including Syft) to currently capture this information. Could you outline the most important bits? Is this something that should make Java binaries have different CPEs/PURLs? |
Thank you for your confirmation and sorry for the confusion.
OK
Sorry, I do not have elegant good idea. I think eclipse-temurin is good sample.
Syft will use To match NVD data, // To focus matching NVD data, using To know EOL, add vendor's CPE like
|
I think this is a great idea! One question we should answer is if there is a consistent way to correlate the binary and the Another question that needs to get answered at the implementation level is where does this arbitrary information land once its extracted by the cataloger? It also needs to structured enough to be able to influence the CPE generation logic. (side note: we've been wanting/needing to push CPE generation logic back to the cataloger packages instead of a centralized package... this would be easier for these kinds of tailorings) |
Thank you for your confirmation.
release file seems in upper directly from
But amazoncorretto:8 do not have release file there
I wrote creating original CPE idea above, but adding new item - {IMPLEMENTOR, PROVIDOR or MENTAINER} in Anyway, this information will not be used widely. (maybe useful for only me ...) |
What would you like to be added:
This it proposal to add provider information.
In this time, I'll write about OpenJDKas sample.
I think there will be similar situation in other product.
Why is this needed:
There are many OpenJDK distributions.
Each distributions have their own lifecycle or support policy (EOL).
In addition, some distribution seems to start registering their CPE in NVD DB.
So, distribution (provider) information is required to match vulns and check EOL.
EOL
NVD
cpe:2.3:a:azul:zulu
is registered sepalately with different version.https://nvd.nist.gov/vuln/detail/CVE-2022-21549
Additional context:
Maybe,
IMPLEMENTOR
inrelease
is good to be used in this case. But path and directory is not unified...eclipse-temurin:17
amazoncorretto:17
azul/zulu-openjdk:17
mcr.microsoft.com/openjdk/jdk:17-ubuntu
sapmachine:17
redhat/ubi8 + java-17-openjdk package
The text was updated successfully, but these errors were encountered: