Repository navigation
Replies: 4 comments 14 replies
|
Hi @idunbarh Thank you for opening this discussion and restarting the previous GitHub issues. I just want to let everyone know that there is a Quarkus team effort going on to provide native SBOM support in Quarkus and offer better transparency (including pedigree, evidence, etc.). I think Alexey Loubyansky (@aloubyansky)from the Quarkus team can provide more information. |
|
Awesome @VinodAnandan! It would be great to hear what the Quarkus team is thinking from @aloubyansky. Part of what we're thinking is around ensuring sboms are more "complete", so it would be good to hear what is already being thought about, and what would need to be "enrichment" of additional metadata. |
|
Keycloak is going a bit beyond a typical Quarkus app by adding an admin CLI "on a side" (JARs + scripts) and a few other files (text ones in the default distribution). Since this content is added after a Quarkus build, Quarkus can't include it in SBOMs it produces.
Depending on what the requirements are for the final SBOM, I think both options could work. |
|
Given that Keycloak actually offers an admin/config capability, with the possibility of customizing the distribution, including adding custom providers, etc, they may want to consider including an option to generate an SBOM for a distribution currently configured. That would basically take the Quarkus SBOM and manifest the rest of content on top of that. |
|
Doing an sbom for java dependencies only is pretty straightforward and there's decent tools to do this, but our problem is we have both Java/maven and pnpm dependencies, and have not found a nice way to do both. I see from your project you are not planning anything for pnpm? |
|
Since maven and pnpm follow separate build processes, I believe it’s perfectly fine to generate SBOMs separately using different tools. For instance, cdxgen ( https://github.com/CycloneDX/cdxgen ) can handle SBOM generation for pnpm projects. If needed, these SBOMs can also be merged using the CycloneDX CLI tool (https://github.com/CycloneDX/cyclonedx-cli#merge-command). However, I think it might be more appropriate to keep them separate, as they are two distinct technologies. |
|
Hello all. Issue #9448 seems to be in stasis. Is anyone working on this? We're looking forward to this feature and we'd also appreciate a separation, as discussed above, if this simplifies the implementation. :-) |
|
There is (in the upcoming release of Quarkus) a way for Quarkus extensions to contribute components and dependencies to the Quarkus SBOM generator. The SBOM could be external, embedded and/or exposed through an endpoint (/.well-known/sbom by default). |
|
@aloubyansky What is the estimated timeline for this upcoming release of Quarkus? |
|
It's still not that straightforward in this case. We do have options. What needs to be clarified is at what degree of data accuracy this actually starts to make sense to the team and consumers. |
|
Adding SBOMs are on our roadmap, and we will deliver on that. I can't say exactly when at this point though as we need to figure out what tool fits best for us (CycloneDX, cdgexn, Trivy, and even the Quarkus extension, are things we will look at). We also need to not just generate some random SBOM, but we need to verify that the actually information inside is valid at least to some extent. As an example if the generated SBOM does not include a dependency for some reason, then having an SBOM can actually be worse than scanning the distribution directly with for instance Trivy. Couple questions though:
|
|
In case of containers, there is an option to attach SBOMs as attestations with cosign. For example, Grype supports reading SBOMs from attestations. But not all scanners support that. |
|
I opened #51743 for review. |
|
For the official Keycloak 26.8.0 linux/amd64 image, are existing build records available that explain the source/component/license pedigree of these two derived archives? Im
8000
age subject:
The generated archive has 1,378 classes and 16 non-class resources; the transformed archive has 175 classes. We verified these bytes and the packaged runtime classpath index. Quarkus 3.40.1 packaging source explains how the generated and transformed build items are archived, but the index/application model does not bind the individual outputs to their producers, actual inputs and source/license records. Could you point to a version-specific SBOM, build record or other supplier declaration that binds these exact outputs to their generating/transforming components and inputs, including copied or modified OpenAPI UI resources? Component/group-level coverage is sufficient if the covered members are explicit. We are looking for existing records before considering a separate reproduction experiment. The observed image build points to Keycloak commit |
|
Do you have an idea/example how it could be expressed? |
Uh oh!
There was an error while loading. Please reload this page.
{{title}}
Uh oh!
There was an error while loading. Please reload this page.
Hi Everyone!
I wanted to see the community's interest in Feature - Include sbom for KeyCloak release #9448.
There is a large CISA Software Bill of Materials Community and some of us are working on a Tiger Team to help create "golden paths" for SBOM generation in Open Source projects. There is a lot of overlap with OpenSSF's SBOM-Everywhere Special Interest Group.
The SBOM Generation Tiger Team is interested in contributing high quality SBOMs to the Keycloak releases as an exemplar.
I'd love to hear feedback on the idea.
All reactions