Don't show versions for external/extraneous dependencies

[raboof]

I think currently all dependencies detected by sbt-sbom would be external/extraneous. Following CycloneDX/specification#321 these should not be included in the output. Perhaps this should be and option (default: follow the spec)

[pjfanning]

Maybe, I've misread CycloneDX/specification#321 but to me that is about non-Maven dependencies
The list of use cases there mentions nothing that is equivalent of a jar that can be fetched from Maven Central.

I don't use CycloneDX SBOMs but any of them that I have used have versions listed. I use the CycloneDX gradle plugin for some Java projects and it defaults to adding versions.
It is fairly configurable and I don't see any config option to omit versions.
https://github.com/CycloneDX/cyclonedx-gradle-plugin

[raboof]

While it's not explicitly called out, my impression is that the Maven ecosystem case is seen as a form of 'dynamic linking': the library is required, but not included, and downstream integrators determine the 'actual' exact version of the library that gets used (which might be different from the one the library was built against).

The cyclonedx maven plugin seems to be going in that direction as well (CycloneDX/cyclonedx-maven-plugin#589)

[pjfanning]

The discussion on that maven plugin issue makes some sense.

I must admit to a bit of disappointment because I liked the idea of the SBOM detailing what the lib version was built with, including the dependency checksums so that you could potentially spot if the build had been affected by a jar that wasn't the correct one. The checksum in the SBOM might not match the one expected (eg in Maven Central). The build could have cached jars in the local repos or the build might have allowed access to a non-standard Maven or Ivy repo.

I kind of think that CycloneDX spec is missing something, if it can't have a built-with-version even if the SBOM itself doesn't suggest what dependency versions are to be used at runtime by lib users.

[raboof]

I must admit to a bit of disappointment because I liked the idea of the SBOM detailing what the lib version was built with

I have the same nagging feeling tbh, but I can't quite place it yet. Perhaps we could shoe-horn the versions the lib was built against into the 'version range' fields somehow? or add that metadata into other 'flexible' fields?

including the dependency checksums so that you could potentially spot if the build had been affected by a jar that wasn't the correct one. The checksum in the SBOM might not match the one expected (eg in Maven Central). The build could have cached jars in the local repos or the build might have allowed access to a non-standard Maven or Ivy repo.

I kind of think that CycloneDX spec is missing something, if it can't have a built-with-version even if the SBOM itself doesn't suggest what dependency versions are to be used at runtime by lib users.

Yeah, though for that use case perhaps you'd even want to include your 'build environment' (i.e. sbt plugins etc that ideally don't 'make it into the build' either) in the SBOM. Perhaps a usecase for producing different 'types' of SBOM?

[raboof]

I kind of think that CycloneDX spec is missing something, if it can't have a built-with-version even if the SBOM itself doesn't suggest what dependency versions are to be used at runtime by lib users.

(FWIW AFAICS SPDX does allow including both 'static' and 'dynamic' libraries, and adding version info for the dynamic ones #89 )