OpenJDK CPEs #2422
Assignees
Labels
bug
Something isn't working
Comments
|
Met with @joshbressers about this issue this morning, and we think that, basically, we need to special-case OpenJDK 8 versions in Syft's CPE generation: This should instead print out something like: |
|
I think it's all java versions prior to 9 that would be prefixed with a 1 in the jdk |
|
The |
|
I wonder if we should have a more specific cataloger for detecting java jdk and jre rather than a generic binary cataloger. For instance, the image |
|
Seems to be present for versions 11 and above at least for the |
|
Sorry, I went off on a bit of a tangent, we'd still need the same sort of adjustments to the CPE generation, I was just looking at getting additional metadata to allow differentiating between various jdk/jre distributions in future |
|
I think we should just special case the version comparison logic in grype and forget about trying to make the CPEs perfect in syft since we know that will never be possible. Instead just have special logic in grype for when we're doing CPE version comparison for these specific packages |
|
Ignore if this isn't helpful, and I'm not a Java expert, but this resonates a lot based on what I'm seeing (from @westonsteimel):
We use Syft/Grype in wolfictl, and noticed it wasn't finding OpenJDK or OpenJDK's published advisories here: https://openjdk.org/groups/vulnerability/advisories/ I saw at least two things contributing to this:
Since this was causing a fair amount of false negatives, I added a last-mile CPE addition in wolfictl based on the distro package name, but I'm not sure if that approach would make sense in Syft's context. Just mentioning this in case it helps us find a good solution upstream here that we can use in wolfictl. 😃 |
|
Some very rough initial notes which may be useful for a future java installation cataloger:
Mayber parse all of the .properties files found under $JAVA_HOME? Also extract the main system properties from the system class (they usually agree with what is in the release file, but that isn't always available, and sometimes the properties map has a bit more info) They seem to be embedded as a map within a java class file. The file I found the map embedded in was classes/java/lang/VersionProps.class from jmods/java.base.jmod - unsure if this will be consitent for prior versions so worth invesitgating further grep -nr '+37' . I also found several properties files which may be worth considering Specifically the llib/javafx.properties file could be useful for understanding which version of javafx is installed javafx in particular is now distributed as a separate project (OpenJFX) and has separate versioning so it would definitely be ideal to capture this as an owned separate dependency. There is more at https://github.com/anchore/vulnerability-data-tools/blob/main/annotation_format_examples/CVE-2024-20925.toml |
|
In case someone was really interested to see all of the jdkjre |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The CPEs that Syft emits for the binary version of OpenJDK versions appear to be incorrect.
For our example of JDK 8 we will use the eclipse-temurin:8u392-b08-jdk image (the openjdk:8 image isn't detected by Syft, which is probably a different bug that needs investigating)
We can see the Java version detected as 1.8.0_392-b08. If we look in the container this checks out
The CPE generated by Syft is then
Which is probably wrong.
If we look at the official CPE dictionary for OpenJDK CPEs we see this (I have trimmed this list for brevity)
The OpenJDK CPE names versus the versions we return in Syft do not match. This is true of OpenJDK8 as well as newer versions. For example if we look at OpenJDK 21
We get CPEs
Based on the above, I would expect the CPE for OpenJDK 21 to look like
The CPE for OpenJDK 8 above I would expect to look like
It looks like versions 8 and before use a different format than newer versions.
The text was updated successfully, but these errors were encountered: