Repository navigation
Distribution SBOM generation - #51743
aloubyansky wants to merge 1 commit into
Conversation
| @@ -2,7 +2,7 @@ | |||
| "name": "root", | |||
| "private": true, | |||
| "type": "module", | |||
| "packageManager": "pnpm@11.1.1", | |||
| "packageManager": "pnpm@11.21.0", | |||
There was a problem hiding this comment.
This was necessary to get the latest pnpm sbom generator.
There was a problem hiding this comment.
This was necessary to get the latest pnpm sbom generator.
@edewit is this fine, please?
There was a problem hiding this comment.
Pull request overview
Adds CycloneDX SBOM generation to the Keycloak distribution.
Changes:
- Generates JavaScript and Quarkus SBOM inputs.
- Merges SBOM data while assembling distribution archives.
- Updates pnpm to support SBOM generation.
Reviewed changes
Copilot reviewed 4 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
quarkus/server/src/main/resources/application.properties |
Configures re-augmentation SBOM behavior. |
quarkus/server/pom.xml |
Adds Quarkus CycloneDX generation. |
quarkus/dist/pom.xml |
Registers the assembly SBOM handler. |
quarkus/dist/assembly.xml |
Merges and packages SBOM data. |
js/pom.xml |
Generates the JavaScript SBOM and updates pnpm. |
js/package.json |
Updates the pinned pnpm version. |
Suppressed comments (1)
quarkus/server/pom.xml:90
- Pass the supported
quarkus.cyclonedx.skipsystem property to override thetruevalue inapplication.properties;enabledis ignored by the extension.
<quarkus.cyclonedx.enabled>${quarkus.cyclonedx.enabled}</quarkus.cyclonedx.enabled>
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
| # disable Quarkus SBOM generation by default, for re-augmentation specifically | ||
| quarkus.cyclonedx.enabled=false |
There was a problem hiding this comment.
| </dependencies> | ||
|
|
||
| <properties> | ||
| <!-- define this as a property, so it can still be overwritten on the CLI --> | ||
| <!-- direct the auto-created files to the target folder, so they are cleaned by "mvn clean" --> | ||
| <kc.home.dir>${project.build.directory}/kc</kc.home.dir> | ||
| <!-- Enable Quarkus SBOM generation for this build --> | ||
| <quarkus.cyclonedx.enabled>true</quarkus.cyclonedx.enabled> |
There was a problem hiding this comment.
| <!-- Generate an SBOM for the NPM packages. | ||
| -prod argument excludes non-production dependencies. W/o it non-production dependencies | ||
| will be appear with scope 'excluded', meaning excluded from runtime --> | ||
| <arguments>sbom --sbom-format cyclonedx --prod --out ${project.build.directory}/js-sbom.cdx.json</arguments> |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 6 changed files in this pull request and generated no new comments.
Suppressed comments (2)
js/pom.xml:136
- Grammar fix in comment: change 'will be appear' to 'will appear' for clarity.
<!-- Generate an SBOM for the NPM packages.
-prod argument excludes non-production dependencies. W/o it non-production dependencies
will be appear with scope 'excluded', meaning excluded from runtime -->
quarkus/server/src/main/resources/application.properties:10
- This sets a module-wide default disabling CycloneDX in
application.properties, whilequarkus/server/pom.xmlenables it via a Maven property/system property for the build. To avoid surprises for anyone invoking different build entrypoints (or re-augmentation flows) consider scoping the disable/enable to an explicit Maven/Quarkus profile (e.g., enable only in a dedicated build profile) rather than having conflicting defaults in resources vs. build configuration.
# disable Quarkus SBOM generation by default, for re-augmentation specifically
quarkus.cyclonedx.enabled=false
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 6 changed files in this pull request and generated no new comments.
Suppressed comments (1)
js/pom.xml:136
- Grammar issue in the comment:
will be appearshould bewill appear.
-prod argument excludes non-production dependencies. W/o it non-production dependencies
will be appear with scope 'excluded', meaning excluded from runtime -->
|
@aloubyansky Thank you very much for the PR, much appreciated! Could you please sign off your commit correctly? It looks like the DCO check is currently failing. You can see the details here: https://github.com/keycloak/keycloak/pull/51743/checks?check_run_id=95063951285 @mabartos could you please start the action workflows ? |
|
@keycloak/cloud-native Could you please check this? Thanks! |
There was a problem hiding this comment.
Thank you very much @aloubyansky . In order to pass DCO you need to sign-off the commit as mentioned above.
I was thinking if we need to follow-up (doesn't necessarily needs to be you) by publishing this SBOM somewhere, maybe as release artifact in GitHub?
I have also mentioned that the final SBOM has only 13 components with the scope, I am totally guessing, but maybe assembly-sbom-handler is dropping them?
I also found it tiny bit confusing calling a build-time dependencies "development". I kept thinking about DEV mode.
| @@ -50,12 +50,18 @@ | |||
| </exclusion> | |||
| </exclusions> | |||
| </dependency> | |||
| <dependency> | |||
| <groupId>io.quarkus</groupId> | |||
| <artifactId>quarkus-cyclonedx</artifactId> | |||
There was a problem hiding this comment.
@aloubyansky do I understand it right that this extension is not supported downstream https://code.quarkus.redhat.com/?e=cyclonedx&extension-search=cyclo ? Is there any plan to support it, maybe in 3.40 or 4.0?
There was a problem hiding this comment.
Good question. I thought it had some support scope but apparently it doesn't. Probably because it's "build time only", which shouldn't matter.
It's been rebuilt from source though since 3.15
https://maven.repository.redhat.com/ga/io/quarkus/quarkus-cyclonedx/
https://maven.repository.redhat.com/ga/io/quarkus/quarkus-cyclonedx-deployment/
There was a problem hiding this comment.
Good question. I thought it had some support scope but apparently it doesn't. Probably because it's "build time only", which shouldn't matter. It's been rebuilt from source though since 3.15 https://maven.repository.redhat.com/ga/io/quarkus/quarkus-cyclonedx/ https://maven.repository.redhat.com/ga/io/quarkus/quarkus-cyclonedx-deployment/
Ok, thanks. I think it should be fine, but we need to hear from others or I'll ask around.
| <dependency> | ||
| <groupId>dev.cyberstamp.maven.assembly.sbom</groupId> | ||
| <artifactId>assembly-sbom-handler</artifactId> | ||
| <version>0.1.1</version> |
There was a problem hiding this comment.
I don't know what is policy on this, so asking others here.
It seems very early dependency 0.1.1, but it was written by @aloubyansky https://github.com/cyberstamp/maven-assembly-sbom and it is only build time dependency for plugin, so it should be alright.
There was a problem hiding this comment.
Right, I intend to support it. There are other projects, such as Artemis, that will integrate it.
Will do.
There are a few options you can consider:
That's a good observation, I'll look into that. FYI, Quarkus is moving away from custom scope properties in favor of CycloneDX excluded scope. It was released in 3.39.0.CR1 (quarkusio/quarkus#55668). I'll generate and share a report of the resulting SBOM analysis |
|
Alright, thanks for the context. |
|
The property merging is fixed now. |
Keycloak Distribution SBOM ReviewOverview
The zip and tar.gz SBOMs have identical component sets; only the main component purl type qualifier differs ( Component InventoryTotals
By CycloneDX type: 760 library, 21 file, 1 application. Maven Groups (top 10)
NPM Package Scopes
Distribution LayoutMaven JARs by Location and Scope
All deployment JARs carry Scope Summary (all components)
The 37 Maven components without scope are: 35 nested (shaded inside parent JARs) + 2 assembly-added ( Nested Components35 components nested inside 6 parent JARs, representing libraries shaded or embedded inside uber JARs:
21 of the 35 also exist as top-level components (the same library appears both standalone and shaded). The License AnalysisCoverage774 out of 782 components have license information (99.0%). 8 components without license:
License Distribution
License Families
Note: some components are dual-licensed, so percentages sum to more than 100%. GPL ComponentsThe 19 The single Dual-Licensed Components (28)
Non-SPDX License Identifiers (6 components)
These originate from the Quarkus SBOM source and would ideally use SPDX IDs for tooling compatibility. Hash Coverage
The 531 Maven components from the Quarkus SBOM carry 8 hash algorithms each: MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512. The 2 Maven components with only SHA-256 are The 35 nested components have no hashes — by design, since the hash belongs to the parent JAR. Evidence and File TraceabilityFile Coverage
Components Without Occurrences (228)
External References
2 Maven components have no external references: Duplicate VersionsMaven
NPM (6 packages)
All are legitimate: the admin and account console themes use different PatternFly generations (PF5 and PF4), which pull different versions of the underlying hast/unist Markdown-to-HTML ecosystem. Dependency Graph
Every component bom-ref — including nested SBOM Generation PipelineThe distribution SBOM is assembled from three sources:
The handler merges these sources, deduplicating by purl, and produces both an external SBOM file and an embedded Items Worth Attention
|
The first 7 would need to be fixed in For I could look into "normalizing" what's straightforward to normalize, otherwise, i guess the same as above. |
|
@aloubyansky I think review may take a while, so if you plan some improvements upstream, that can be done in parallel. let see |
|
@shawkins / @edewit / @Pepo48 / @vmuzikar / @stianst Could you please help with reviewing this PR when you get a chance? I believe it would provide significant value to the Keycloak community, as it would allow Keycloak users to access and make better use of third-party component information and the associated licence details in a more structured and usable format than HTML. |
This PR adds SBOM generation to the Keycloak distribution.
Fixes #9448
Given the distribution is assembled from builds of different modules, SBOM generation also consists of a few steps.
PNPM
The
jsmodule produces an SBOM usingpnpm sbom. AFAICT, that's one of the best SBOM generators in the Node.js ecosystem.I added
--prodargument to exclude non-prod dependencies. Although it could be omitted, in which case non-prod dependencies will be added with scopeexcluded, which should indicate to the scanners that a package is not a part of runtime.Quarkus
Given it's a Quarkus application, to get it accurately manifested,
quarkus-cyclonedxextension was added as a dependency. It is however disabled inapplication.propertiesto not generate SBOMs on re-augmentation. But it is enabled for the Keycloak build itself.The purpose of the Quarkus SBOM generator is to properly identify all the Maven artifacts that make up the Quarkus app.
Refer to https://quarkus.io/guides/cyclonedx for options but it should be good as-is.
Maven assembly
This is where the distribution is finalized. The SBOM here is generated with
assembly-sbom-handlerconfigured as a plugin into the assembly Maven plugin.This SBOM generator tracks everything that gets packaged and takes the
jsand thequarkusSBOMs as extra sources of component information.I added some comments on a few most relevant configuration options. Refer to https://github.com/cyberstamp/maven-assembly-sbom#assembly-handler for more.
I am not sure generating both embedded and external SBOMs at the same time is necessary but it was easy to check the results.