Hi Piotr, thanks for the feedback. That info was very useful!
I am now looking into the configuration of the maven plugins in order to generate better SBOM files. I was under the impression that the plugins will get license and copyright infos from the source files, but now I understand that this is part of the plugin configuration. I'm not yet done with adapting the configuration, so I might come up with some more questions, if you don't mind. I tried your sbom-enforcer plugin, but w/o success. I always run into the following error: [ERROR] Failed to execute goal io.github.sbom-enforcer:sbom-enforcer-maven-plugin:0.2.0:check (default-cli) on project jdo-api: Unable to parse configuration of mojo io.github.sbom-enforcer:sbom-enforcer-maven-plugin:0.2.0:check for parameter privateLocalRepoPath: Cannot create instance of interface java.nio.file.Path: java.nio.file.Path.<init>() This might be due to a configuration problem at my end. I tried adding parameters usePrivateLocalRepo and privateLocalRepoPath - no difference. Some minor remarks about the documentation of the sbom-enforcer plugin * The sample plugin configuration most probably misses a tag <execution> inside of <executions> * The github README misses the <rules> tag and uses a tag called <verifyReferences> instead of <validateReferences> * Does the plugin assume the SBOM files generated by the cycloneDX plugin to be bom.json and bom.xml? There is a cycloneDX option outputName to change the file name. So you might need a parameter to specify the SBOM file name.parameter Regards Michael On 2025/09/08 06:13:32 "Piotr P. Karwasz" wrote: > > Hi Michael, > > On 6.09.2025 18:53, Michael Bouschen wrote: > > The api jar file is the only jar file released by the JDO project (see > > https://github.com/apache/db-jdo/tree/main/api). > > When using the above maven plugin the following SBOM files are created: > > > > * cyclonedx: jdo-api-3.3-SNAPSHOT-cyclonedx.json and jdo-api-3.3- > > SNAPSHOT-cyclonedx.xml > > * spdx: jdo-api-3.3-SNAPSHOT-spdx.json > > > > I was surprised the generated SBOM files are very different in size, > > structure and content. You find the files attached to this email. > > > > Do you have any recommendations with respect to SBOM files? > > How to create them? What should be included? How to use them? > > These are excellent questions, thanks for raising them! > > SBOMs generally serve two main purposes: > > 1. License compliance. This was the original motivation, and it remains > the top concern for many companies, as the risk of lawsuits is taken > very seriously. > 2. Vulnerability management. For Java applications, SBOMs can be used to > detect vulnerabilities in bundled components. For libraries, however, > their value is limited. Since dependencies aren’t shipped (except in > cases like shading), and version information is just a suggestion, > it’s usually the responsibility of the application to update > vulnerable transitive dependencies. > > What should be included > ----------------------- > > The size and structure differences you noticed between CycloneDX and > SPDX SBOMs stem from their different levels of granularity: > > - CycloneDX focuses on packaged software. > - SPDX can describe components down to the file level. > > At Apache Logging, we don’t publish SPDX files. If you’d like, you can > reduce their verbosity by using the `sbomType` option [1] to avoid > listing individual files. It’s also worth noting that the plugin didn’t > detect the ASF license header in the source files, so some additional > configuration is needed. > > You may also want to exclude certain Maven scopes: removing `test` > dependencies is usually a good idea. > > How to use them > --------------- > > For libraries, SBOMs aren’t yet very practical for vulnerability > management. SPDX does have richer relationship types [3] (e.g., > DEPENDS_ON, INCLUDED, DYNAMIC_LINK, STATIC_LINK), which can distinguish > shipped from non-shipped dependencies. In the CycloneDX Maven Plugin, > this distinction is still being worked out [4]. Shipped dependencies are > the most important, since fixing vulnerabilities in them requires a new > release. > > For now, SBOMs are most useful for: > > - Verifying license compliance > - Collecting metadata (e.g., project website, contact info, etc.) > > I’ve also been experimenting in this area. A few months ago, I wrote a > small Maven plugin (SBOM Enforcer [2]), which validates SBOMs by > checking URL links and hashes. Expanding this to fetch and verify SBOMs > from dependencies against your own metadata is on the roadmap. > > Best regards, > Piotr > > [1] https://spdx.github.io/spdx-maven-plugin/createSPDX-mojo.html#sbomType > [2] https://github.com/sbom-enforcer/sbom-enforcer > [3] > https://spdx.github.io/spdx-spec/v2.3/relationships-between-SPDX-elements/ > [4] https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/589 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Michael Bouschen akquinet tech@spree GmbH Bülowstraße 66 • D-10783 Berlin Tel: +49 40 8817 31180 Fax: +49 30 217520-12 E-Mail: [email protected] Web: www.akquinet.de <http://www.akquinet.de/> Geschäftsführung: Dr. Torsten Fink, Heinz Wilming Amtsgericht Berlin HRB 86780 • USt.-Id. Nr.: DE 225 964 680 [LinkedIn] <https://www.linkedin.com/company/akquinet/> [xing] <https://www.xing.com/companies/akquinetag> [kununu] <https://www.kununu.com/de/akquinet> [Instagram] <https://www.instagram.com/akquinet_/>
smime.p7s
Description: S/MIME cryptographic signature
