Produce SBOM and deploy to Maven Central #9502
Comments
|
https://snyk.io/blog/create-sboms-java-maven-gradle/ I don't know if an XML based SBOM or a SPDC based SBOM is better. @olamy do you know of any other projects that publish SBOMs to maven central? |
|
I don't have strong opinions here. But what do we include in the sbom? |
|
I would say we publish anything we deploy to maven central on a groupId that starts with |
|
@joakime remind me why do we need a SBOM and how's different from the BOM? |
|
Maven BOM is just maven coordinate space with versions. SBOM has more information (in a condensed form), suitable for various tooling built around auditing of of dependencies (are you using the most current version? is the same version as the developer released? etc). CVE databases are starting to use these SBOMs to identify specific artifacts that are good/bad too. This is an example of an XML form of SBOM .... <component type="library" bom-ref="pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4?type=jar">
<publisher>FasterXML</publisher>
<group>com.fasterxml.jackson.core</group>
<name>jackson-databind</name>
<version>2.13.4</version>
<description>General data-binding functionality for Jackson: works on core streaming API</description>
<hashes>
<hash alg="MD5">03cb7aea126610e4c96ca6d14d75cc55</hash>
<hash alg="SHA-1">98b0edfa8e4084078f10b7b356c300ded4a71491</hash>
<hash alg="SHA-256">c9faff420d9e2c7e1e4711dbeebec2506a32c9942027211c5c293d8d87807eb6</hash>
<hash alg="SHA-512">23f32026b181c6c71efc7789a8420c7d5cbcfb15f7696657e75f9cbe3635d13a88634b5db3c344deb914b719d60e3a9bfc1b63fa23152394e1e70b8e7bcd2116</hash>
<hash alg="SHA-384">e25e844575891b2f3bcb2fdc67ae9fadf54d2836052c9ea2c045f1375eaa97e4780cd6752bef0ebc658fa17400c55268</hash>
<hash alg="SHA3-384">e6955877c2c27327f6814f06d681118be2ae1a36bc5ff2e84ad27f213203bf77c347ba18d9abc61d5f1c99b6e81f6c2d</hash>
<hash alg="SHA3-256">88b12b0643a4791fa5cd0c5e30bc2631903870cf916c8a1b4198c856fd91e5f4</hash>
<hash alg="SHA3-512">7e86a69bcf7b4c8a6949acce0ec15f33b74d5ac604f23cd631ec16bfdfd70d42499028b9d062648b31d7a187ea4dc98ec296a329f4cfd4952744ed1281fa9d9a</hash>
</hashes>
<licenses>
<license>
<id>Apache-2.0</id>
</license>
</licenses>
<purl>pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4?type=jar</purl>
<externalReferences>
<reference type="vcs">
<url>http://github.com/FasterXML/jackson-databind</url>
</reference>
<reference type="website">
<url>http://fasterxml.com/</url>
</reference>
<reference type="distribution">
<url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
</reference>
</externalReferences>
</component>This is an example of an SPDX / SPDC form of SBOM ... |
|
All this information is already in Maven Central. |
|
You'd think so, but no.
Some history here https://learn.sonatype.com/guides-old/sboms-explained/ And other tools to generate them here https://blog.sonatype.com/5-tools-to-automate-sbom-creation |
|
The next question after publishing an SBOM is usually how consumable it is, each of the tool listed https://blog.sonatype.com/5-tools-to-automate-sbom-creation have different levels of maturity. We have created an open source sbom quality scoring tool, which can help with this process. https://github.com/interlynk-io/sbomqs |
sounds good. cc @hboutemy |
|
yes, given your build is done with Maven, cyclonedx-maven-plugin looks like a good and easy solution |
The Jetty 12 environment means we'll have ...
This is because the transitive dependencies from the ee# level are different, and cannot converge. |
|
@waynebeaton recently put out a call to the Architecture Council to look at this issue. There is a lot of information regarding the direction Eclipse is taking here. |
|
I had a bit of try with that (see PR #10877). |
|
@olamy can the top level bom at least excluded things that are never deployed? (test modules) |
|
Based on yesterday's Architecture Council discussion, it only makes sense for the SBOM to be generated for the jetty-home artifact. There is a slew of broad-scoped extensions to SBOMs, but no actual standard is emerging for intended use cases; most organizations appear just to be trying to 'tic a box' that they have SBOMs. At this point, an SBOM that describes the contents of a zip file or a tarball is the bare minimum of what people are looking for. This is subject to change, but if we achieve that, we meet the brief. @waynebeaton fair? |
|
I should also mention that in maven land, the quality of the artifact metadata is the key factor in our producing a good SBOM, or an embedded jetty user building an SBOM for their product. With that in mind, @waynebeaton opened an issue for maven enforcer rules to help projects make sure they have the basic needs met. Assuming the enforcer plugin can do it. |
yes. Have a look at the PR (#10877), every single module with Log output I have made some changes to produce only a single sbom from top project. |
|
@waynebeaton what do you think about the sbom content? Does it need to cover only what we distribute directly via the jetty-home distribution zip or do we need to cover everything, including optional modules that will be installed by users only on demand (but still deployed to Maven central though) |
|
The only thing we should worry about right now is an SBOM that is accurate for the jetty-home distribution, ideally including it within the artifact. The stock distribution for the time being. Until there is more clarity on what someone requires from an artifact's SBOM there is no point in producing them. The SBOM is generated from the maven metadata, so if they are trying to produce an SBOM for their product, they will just mine the maven metadata. This will work right up until SBOMs contain industry-demanded data that is not tracked within maven. No one really knows what that is yet, way too much churn going on. Let's just do the bare minimum for the time being until someone can make a meaningful case for more. All these things are for most organizations at this point is a compliance checkbox. |
|
@jmcc0nn3ll just to be clear I'm interpreting what you wrote as ...
Is that what you mean? |
|
We can put the SBOM in Maven Central as a classified artifact alongside the jetty-home, but it should go in it as well I think. Currently, based on what we know about SBOMs from the last AC meeting, the SBOM is a file that describes what is included in the thing you just downloaded. So, in our case, it is a descriptor detailing what is on disk in that zip or tarball. The current intended purpose is that the downloader knows precisely what is inside the thing they just downloaded and installed. I think of the SBOM as a way that the downstream consumer can cross that file against a vulnerability database and know if that zip or tarball is vulnerable. The scope of this is likely going to grow broader as the whole SBOM ecosystem develops, but for now, it is enough to have an SBOM that describes what is in this thing you just downloaded. I see no value in SBOMing all the things when there isn't a clear intended purpose or use case for that. |
|
This has been implemented in the PR #10877 . I don't like much the classifier used by the CycloneDX plugin for the attached sbom. |
|
well it looks I forgot about this sbom formats/specs "war" :) this classifier is definitely not a good idea. |
…include it in the distribution (#10877) * sbom for jetty home only * include the sbom in the distribution * included sbom cyclonedx to have same name as deployed to Maven central --------- Signed-off-by: Olivier Lamy <olamy@apache.org>
Jetty version(s)
Jetty 12
Enhancement Description
We should produce an SBOM and have it be published to maven central somwhere.
Perhaps as an attached artifact on
jetty-bomor as a new artifactjetty-sbom?The text was updated successfully, but these errors were encountered: