Adding metadata to SBOM Reporters

[FabianRolfMatthiasNoll]

What is the functionality you want to propose?

Given the rising need of SBOM creation especially in professional sectors like industry and medicine etc some things are starting to be defined what such a SBOM has to have. In the recent FDA update SBOMs are now mandatory. Those SBOMs must have data like the manufacturer / author / and or supplier embedded. As of now given the metadata this is besides the timestamp the only requirement.

My proposal is a easy way to set this data either per the config.yml or the .ort.yml or as flags and this is added in the reporting state of the SBOM. Currently this is implemented for the SPDX output but not for CycloneDX

What is the use-case for your enhancement?

Probably every user which is mandated to create SBOMs for audits

Alternatives you have considered

The alternate solution is currently at least in my workflow to have a jq command that injects that info into the SBOM.

[mnonnenmacher]

@FabianRolfMatthiasNoll Could you provide the full list of properties you would like to be able to set, ideally with links to the CycloneDX spec?

[sschuberth]

hose SBOMs must have data like the manufacturer / author / and or supplier embedded.

Also see #7449.

[FabianRolfMatthiasNoll]

So the properties that should minimally be able to set in my view is:
The manufacturer: https://cyclonedx.org/docs/1.7/json/#metadata_manufacturer
because we are working in a automated way the author field is not relevant here i think.
Also in the same thing the supplier would be beneficial: https://cyclonedx.org/docs/1.7/json/#metadata_supplier
In most cases this is the same as the manufacturer but as described another company could be the supplier of the component we describe in the bom but another company creates the BOM.

Optionally the lifecycle property could be a interesting aspect in companies and we would definitily use it. https://cyclonedx.org/docs/1.7/json/#metadata_lifecycles

[maennchen]

I agree that being able to set these properties would be important. In particular, having explicit control over manufacturer / supplier for both the metadata and individual components matters for compliance and downstream processing.

Related to that, I also think it would be beneficial if plugins (scanners, analyzers, etc.) could declare additional components for the metadata.tools section. Some tools are effectively part of the SBOM generation chain even if they’re not the “primary” ORT tool, and being able to model that explicitly would improve transparency and accuracy.

[FabianRolfMatthiasNoll]

Oh yeah this is also definitly a good thing that future releases should have. Like scancode beeing used in the toolchain etc. As far as i know this is currently not a requirement but one i could see coming in the future.
Im happy that ORT writes itself as a tool in the metadata because thats something many sbom tools currently just dont do