SBOM for custom jlink JRE

[tortoiseparrot]

Using Spring Boot and its Maven plugin to create an image with a custom JRE I'm a bit puzzled.

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <image>
            <env>
                <!-- https://github.com/paketo-buildpacks/amazon-corretto#configuration -->
                <BP_JVM_JLINK_ENABLED>true</BP_JVM_JLINK_ENABLED>
                <BP_JVM_JLINK_ARGS>--add-modules java.base,…,jdk.naming.dns --compress=2 --no-header-files --no-man-pages</BP_JVM_JLINK_ARGS>
            </env>
            <!-- use amazon-corretto instead of bellsoft-liberica, see https://github.com/spring-projects/spring-boot/issues/25561#issuecomment-795615788 -->
            <buildpacks>
                <buildpack>paketobuildpacks/amazon-corretto</buildpack>
                <buildpack>paketo-buildpacks/java</buildpack>
            </buildpacks>
        </image>
    </configuration>
</plugin>

From what I can tell so far this image is working as intended.
However I can't seem to find the JVM version in the SBOM and I believe that a Paketo buildback should have added it somewhere.

According to the build log:

Downloading from https://corretto.aws/downloads/resources/11.0.18.10.1/amazon-corretto-11.0.18.10.1-linux-x64.tar.gz

According to paketo-buildpacks/amazon-corretto/buildpack.toml:

  [[metadata.dependencies]]
    cpes = ["cpe:2.3:a:oracle:jdk:11.0.18:*:*:*:*:*:*:*", "cpe:2.3:a:amazon:corretto:11.0.18:*:*:*:*:*:*:*"]
    purl = "pkg:generic/amazon/[email protected]"
    sha256 = "40baac37cb9a3953bba01c07f34782bf4d80a7529009641278e42ca674ff9ee8"
    uri = "https://corretto.aws/downloads/resources/11.0.18.10.1/amazon-corretto-11.0.18.10.1-linux-x64.tar.gz"
    version = "11.0.18"

I've downloaded the SBOM files using the pack CLI as per https://paketo.io/docs/howto/sbom/#access-syft-cyclonedx-and-spdx-sboms

Now I would have expected to find the precise JVM version (11.0.18.10.1 / 11.0.18.10 / 11.0.18) somewhere.
However the closest matches are layers/sbom/launch/paketo-buildpacks_executable-jar/sbom.syft.json:

"Java-Version": "11.0.13",
"Created-By": "11.0.11 (AdoptOpenJDK)",
"Build-Jdk": "11.0.2",

I'm still reading up on SBOMs in general and the different formats, but none of those versions seem to be my buildpack runtime JRE version?
Am I looking in the wrong places, is my specific use-case with custom jlink JRE unsupported for SBOM generation and if so - why?

[zQQp]

I am also curious how the selection of the version is managed 🤔

[dmikusa]

Sorry for the delayed response. I suspect what's happening is this.

1. You run a build.
2. The buildpack installs the JDK at build-time only. This JDK includes jlink.
3. It runs jlink to produce a stripped-down version of the JDK, which goes into the runtime image.
4. The instructions you linked to are for downloading the runtime image's SBOM, so you don't see anything (more on that below).
5. If you follow these instructions to fetch the build-time SBOM I'm almost 100% positive you'll see the JDK listed.

I'm guessing that you're not seeing it listed at runtime because there is a gap here. We add SBOM entries for dependencies that are installed, but there is no direct dependency for what gets installed into the runtime environment. What's installed is a dynamically generated subset of the JDK dependency.

I'm not sure it makes sense to have the JDK dependency listed at runtime, because it doesn't technically exist and it could create false positives for scanners. At the same time, it's hard to describe what actually gets installed into the runtime container because it's dynamically added and user-customizable.

I don't think I have a good answer for how this should work, so I'd really like to get feedback on what everyone thinks. How would you all like this to work? Do you know of any prior art in this area? Perhaps other tools that generate SBOMs, how do those handle jlink created runtimes? Thanks

[tortoiseparrot]

Given that I am using spring-boot-maven-plugin, how would I run a matching pack build myapp --sbom-output-dir /tmp/build-time-sbom ?
Is there no other way to retrieve the build-time dependencies of an existing image, is this info lost?

Given that the custom JRE is created by a paketo buildpack itself I don't see why it couldn't use the BP_JVM_JLINK_ARGS modules input configuration for SBOM generation or extract that info from the generated JRE.
While error prone when done manually, is there a way as a user to hook into the SBOM generation and contribute entries, other than with a whole builder / buildpack?

From what I understand, in general the build-time JDK and the generated JRE version do not have to match, but they do with this buildpack. Yet it is an error to not include any info about the JRE in the runtime SBOM at all.
It would be good to include SBOM info on the included JRE modules aswell, but I'm not aware of a standardized approach for this. Additional difficulty here being that one can add both standard/proprietary JDK modules as well as custom ones and e.g. their purl might not be readily available or agreed upon.

I am not sure if such granular SBOM info could be used already. So far CVEs are filed for entire JDK/JRE versions, not specific modules and I'm not aware of a more detailed vulnerability data source that's specific to how JRE modules work.
I have not checked how and if other tools such as Trivy detect such a custom JRE, but they probably rely on the info being present in another package system such as apt/apk/yum etc.

At the very least I would expect the overall JDK version to show up in the runtime SBOM. With this info missing I can not rely on the paketo SBOM and have to use other tools or post-processing.

[dmikusa]

Given that I am using spring-boot-maven-plugin, how would I run a matching pack build myapp --sbom-output-dir /tmp/build-time-sbom ?

I don't believe that's possible. I don't see an option for that in the Spring Boot build tools docs. @scottfrederick Is this possible? or something on the roadmap?

Is there no other way to retrieve the build-time dependencies of an existing image, is this info lost?

I don't know if it's stored anywhere beyond the build. I can ask.

Given that the custom JRE is created by a paketo buildpack itself I don't see why it couldn't use the BP_JVM_JLINK_ARGS modules input configuration for SBOM generation or extract that info from the generated JRE.

I'm not following 100%. When you get it to download the build SBOM, maybe take that and mock up what you'd like the output to look like. If you give me an example of what you think it should look like, that's probably the easiest path forward.

While error prone when done manually, is there a way as a user to hook into the SBOM generation and contribute entries, other than with a whole builder / buildpack?

You can make your own buildpack, and have that contribute. It will incorporate results into the overall set.

I'm not sure about having a raw user-controlled option for contributing to the SBOM. I can see some value in that, but I also worry that if there's too much user control then it might allow someone to compromise the data. If we did allow users to contribute SBOM details, then it would probably have to be through a separate "user-sbom" buildpack, so the results are separate and added to the overall set (i.e. you couldn't override something set by another buildpack).

From what I understand, in general the build-time JDK and the generated JRE version do not have to match, but they do with this buildpack. Yet it is an error to not include any info about the JRE in the runtime SBOM at all.
It would be good to include SBOM info on the included JRE modules aswell, but I'm not aware of a standardized approach for this. Additional difficulty here being that one can add both standard/proprietary JDK modules as well as custom ones and e.g. their purl might not be readily available or agreed upon.

I am not sure if such granular SBOM info could be used already. So far CVEs are filed for entire JDK/JRE versions, not specific modules and I'm not aware of a more detailed vulnerability data source that's specific to how JRE modules work.
I have not checked how and if other tools such as Trivy detect such a custom JRE, but they probably rely on the info being present in another package system such as apt/apk/yum etc.

At the very least I would expect the overall JDK version to show up in the runtime SBOM. With this info missing I can not rely on the paketo SBOM and have to use other tools or post-processing.

Yes, this is the million-dollar question. How to represent this in the SBOM such that it properly triggers detection when there's a CVE.

One option is to just include the JDK at runtime, but I'm sure that's going to trip up folks on the opposite side with false positives.

[scottfrederick]

Given that I am using spring-boot-maven-plugin, how would I run a matching pack build myapp --sbom-output-dir /tmp/build-time-sbom ?

The Spring Boot Maven and Gradle plugins don't have an option that matches pack's --sbom-output-dir. If that's desired, feel free to create an issue and we'll look into it.

[tortoiseparrot]

The Spring Boot Maven and Gradle plugins don't have an option that matches pack's --sbom-output-dir. If that's desired, feel free to create an issue and we'll look into it.

I don't know if it's stored anywhere beyond the build. I can ask.

If the JRE/JDK version and possibly modules were included in the runtime SBOM, I would not need the build-time SBOM. As-is however I can not even check if the JRE/JDK is included in the latter.

I'm not following 100%. When you get it to download the build SBOM, maybe take that and mock up what you'd like the output to look like. If you give me an example of what you think it should look like, that's probably the easiest path forward.

This was just a remark that the paketo buildpack has all the input it needs or could extract it from its output. So contributing the JRE/JDK/module SBOM info is not something that could only be done by me as a user.

I'm not sure about having a raw user-controlled option for contributing to the SBOM. I can see some value in that, but I also worry that if there's too much user control then it might allow someone to compromise the data. If we did allow users to contribute SBOM details, then it would probably have to be through a separate "user-sbom" buildpack, so the results are separate and added to the overall set (i.e. you couldn't override something set by another buildpack).

Fair enough, this was just an idea to enable a workaround by me as a user for something that could be done by the paketo buildpacks. It might not be needed as a feature in general.

Yes, this is the million-dollar question. How to represent this in the SBOM such that it properly triggers detection when there's a CVE.

How does the used JDK look like in the build-time SBOM?

One option is to just include the JDK at runtime, but I'm sure that's going to trip up folks on the opposite side with false positives.

Inclusion in the SBOM could be configurable for the buildpack. However I would argue that including too broad info "this includes (a whole) JDK with version x.y.z" is better than not having that info at all (incomplete SBOM). Furthermore CVE as a data source currently has issues with false positives anyways, since it doesn't usually go down to "only applicable if you use class/script/object abc from version x.y.z" and is just "probably applicable if you use/depend on library/framework/application version x.y.z".
The SBOM doesn't describe whether one actually uses certain code, just if it is present and could thus be used.

From a different perspective, I would like to answer questions using the SBOM such as:

• which JRE/JDK and version does the image use, does it still have support (e.g. Corretto 8 LTS)?
• which JRE/JDK and version does the image use, is "Spring4Shell" likely to apply?

For now I suggest ignoring which modules the generated JRE contains, since there's no state of the art SBOM for that.
I would rather just have the paketo buildpack include the JRE/JDK info that's in the build-time SBOM in the runtime SBOM aswell.