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]
