Can/should (maven) plugins be added to the SBOM?

[lkleeven]

In short: Since maven plugins are able to add code (code generation) and potentially have other impact on the software that is delivered. Shouldn't the maven plugins that are used in a project be added to the SBOM? And if so, can it this functionality be added to the Cyclone DX maven plugin?

Some more context: We build a framework and tools that are used within our company to quickly build applications. We (mis)use the Cyclone DX maven plugin to report on the maven dependencies being used. However, we also provide maven plugins for various purposes. For our use case we'd also like to measure their usage. But since plugins can also be used to alter/create software, we thought this would be a good fit for addition to the Cyclone DX maven plugin. Reading the description of 'component' it seems that a maven plugin would fit very well in there too. Hence this question/feature request.

[hboutemy]

We (mis)use the Cyclone DX maven plugin to report on the maven dependencies being used

I would not call that mis-using: this is what SBOM are about at first, AFAIK

on adding more details on the plugins used to build (Maven way to says "the build process", or anything that "have an impact on software that is delivered"), it's a topic added in most recent CycloneDX versions as "formulation" https://cyclonedx.org/specification/overview/#formulation . To me, this is not a priority, as we have so many aspects yet to solve on the dependencies aspect (and personally, I feel that formulation is a nice theoretical dream, but I don't see how logging a Maven build will help consumers in a concrete way: it will IMHO add just a lot of noisy content. But that's just a quick personal thinking, nobody is forced to agree :) I will just personally not focus on that huge new road unless someone proves me it adds actionable value given the foreseeable maturity on SBOMs for the next 5 years)