Thanks for sharing this.  Though I couldn’t attend this live session earlier, the recording was quite informative specifically around the ‘SBOM types’ and ‘SPDX-3.0 support for multiple profiles’.

Hi Alexios,

Question:  In the context of ‘SBOM types’,  any thoughts on whether each of these types will be more relevant or less relevant (from the associated data stand-point) to specific profiles that are supported in SPDX-3.0 ?  For example, in order to specify/record all details pertaining to ‘Analyzed’ (AKA 3^rd party) SBOMs, do you think a SPDX-3.0 ‘license’ profile might be more suitable and effective than other profiles say ‘Software profile’ or ‘build profile’ ?  

Appreciate your thoughts on this.

Hi Prasad, thanks for asking.

The “types” of SBOMs are more related to the point in the software development lifecycle when they are generated.

The “profiles” in SPDXv3 are more related to “areas of interest” of the different information that one can have on software components.

Therefore I see these two as orthogonal dimensions: for each type of SBOM one may or may not include licensing or build information, for example.

Obviously some combinations do not make sense: in the design phase one does not have build information, typically.

But I think it all ultimately depends on the use case – and SPDX gives you the flexibility to produce compliant documents in all cases.

Thanks for the response.  Agree, it totally makes sense to consider the ‘Types of SBOMs’ Vs ‘SPDX Profile types’ to be orthogonal while at the same time, also recognizing a few SPDX profiles have less relevancy to some SBOM types as you’d pointed out.  

A comment/feedback - One potential area (perhaps, this is already covered within ‘Security profile’ ?) to specify/record will include information pertaining to TLS/SSL certs (such as Cert. serial no., Issuing CA, Exp. date etc.) that are associated with a web or cloud hosted software or services. In case this is not fully addressed in SPDX-3.0, can we’ve a provision to define and include a separate profile (say ‘Associated CA’ profile) in 3.1 ?  Glad to discuss / collaborate further on this offline.

Hi Prasad, thanks for asking.

The “types” of SBOMs are more related to the point in the software development lifecycle when they are generated.

The “profiles” in SPDXv3 are more related to “areas of interest” of the different information that one can have on software components.

Therefore I see these two as orthogonal dimensions: for each type of SBOM one may or may not include licensing or build information, for example.

Obviously some combinations do not make sense: in the design phase one does not have build information, typically.

But I think it all ultimately depends on the use case – and SPDX gives you the flexibility to produce compliant documents in all cases.