Do SBOMs make sense for individual Eclipse Platform Plug-ins?
By their nature, individual Eclipse Platform Plug-ins specify version ranges for their dependencies. In isolation, it is meaningless to provide a list of (version specific) dependencies in an SBOM, since what will actually get resolved at assembly time may be very different depending on configuration.
Rather, it makes more sense to talk about an SBOM for the aggregation of components. That is, it makes sense to create an SBOM for each of the Eclipse IDE packages. Our thinking is that we should focus on that.
Some options, followed by random musings:
- Modify the tools used to assemble packages (Eclipse Tycho); or
- Create a tool that scans the plug-ins directory to assemble a component list, extract license information and other metadata and use that information to generate an SBOM.
At a minimum... in order to be successful, we'll need to ensure that we have complete metadata. That is, we'll need to work with project teams to ensure that all plug-ins include an about.html
that we can scan for license information.
As part of a modernisation effort, we might consider getting project teams to include license information as SPDX identifiers or expressions in their MANIFEST.MF
(which would reduce entropy in determining license information).
Comments welcome.