feature: generate sboms for all published binary jar files

[jdaugherty]

With the recent compromises of NPM, it's important we publish an SBOM.

This change generates sboms per the recommended standard. The files will not be published individually at this time (publish plugin needs enhancements). Instead, the files will be published inside of the binary jar files at META-INF/sbom.json.

Other notes on this PR:

• As part of testing the cyclonedx gradle plugin, there are some quality issues with the plugin. It does not support the latest best practices for gradle. There is a 3.x version upcoming, but it's still alpha and has other issues (you can't set the component type).
• I discovered we were generating jar files with just license / ASF policy files, so I've stopped generating those files as of this change (grails-dependencies-*,etc)
• I'm not creating an aggregate sbom for the Grails framework. Right now, an individual sbom for every project will be generated.
• I'm not widely documenting this feature at the start since we'll want to review all of these sboms. Security software is the main target of these files, so it will find them on it's own.

[jdaugherty]

I've gone ahead and updated this PR to also strictly validate licenses based on current versions. This means that as we update dependencies in the future, we can adjust our exceptions/ mappings and be confident there hasn't been a license change.

[jamesfredley]

Great work!

[matrei]

I'm getting:

Unpermitted License found for bom dependency: pkg:maven/org.hdrhistogram/[email protected]?type=jar in project grails-dependencies-starter-web : CC0-1.0

when running ./gradlew clean cyclonedxBom: https://ge.grails.org/s/y74nwrngrwqtq

[jdaugherty]

The starter projects don't generate a jar so they don't run the license check by default. I guess I could depend on assemble instead ... let me make that change and fix the fallout

[jdaugherty]

@matrei I populated most of the other licenses that the ASF considers acceptable from https://www.apache.org/legal/resolved.html & run the validation on assemble as well. This fixes the error you're seeing from the spring actuator project.

[matrei]

Do we need to include the license texts in the SBOMs?

[jdaugherty]

Do we need to include the license texts in the SBOMs?

I'm not sure if I understand this - are you proposing we don't include the text or are you asking us to?

The SPDX code is what identifies the license text. The cyclonedx is a json standard, so we're simply including what the upstream authors have published. Most of the licenses are included via a base64 encoding. We could technically strip the text and ensure the id is present. I'm inclined to use what the standard does by default since this is meant for security review.

[matrei]

I'm not sure if I understand this - are you proposing we don't include the text or are you asking us to?

The SPDX code is what identifies the license text. The cyclonedx is a json standard, so we're simply including what the upstream authors have published. Most of the licenses are included via a base64 encoding. We could technically strip the text and ensure the id is present. I'm inclined to use what the standard does by default since this is meant for security review.

I'm wondering if there is any downside to set the includeLicenseText property to false (https://github.com/CycloneDX/cyclonedx-gradle-plugin?tab=readme-ov-file#configuration-properties).

[jdaugherty]

I'm not sure if I understand this - are you proposing we don't include the text or are you asking us to?

The SPDX code is what identifies the license text. The cyclonedx is a json standard, so we're simply including what the upstream authors have published. Most of the licenses are included via a base64 encoding. We could technically strip the text and ensure the id is present. I'm inclined to use what the standard does by default since this is meant for security review.

I'm wondering if there is any downside to set the includeLicenseText property to false (https://github.com/CycloneDX/cyclonedx-gradle-plugin?tab=readme-ov-file#configuration-properties).

One downside is there isn't an SPDX code for the sitemesh license. The actual standard only requires id or name though. https://cyclonedx.org/docs/1.6/json/#tab-pane_components_items_licenses_oneOf_i0_items_license_oneOf_i0

Why would you want to not include the license text?

[matrei]

Why would you want to not include the license text?

I was thinking about jar size.

[jdaugherty]

Let me check the sizes but they are zipped so I wasn’t expecting a significant increase. Will circle back this afternoon.

…

On Mon, Sep 22, 2025 at 2:44 PM Mattias Reichel ***@***.***> wrote: *matrei* left a comment (apache/grails-core#15087) <#15087 (comment)> Why would you want to not include the license text? I was thinking about jar size. — Reply to this email directly, view it on GitHub <#15087 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR5JT3NYBK5LMMJMWVCLBD3UA7RFAVCNFSM6AAAAACG53WNAOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRQG44DQNRVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jdaugherty]

File sizes for the hibernate-core.jar:

1. has license text: 655K
2. no license text: 588K

I guess with the base64 encoding, zip can't optimize the sizes so it seems reasonable to turn off the text include.

[matrei]

Great work James! 🎉

[matrei]

Space after if?

[jdaugherty]

I would have assumed codenarc was applied to our gradle files, but apparently not. Do you know if it's possible to apply our code style rules to gradle files?