search

OpenChain-Project / Telco-WG

This is the OpenChain Telco Work Group
Other
13 stars 6 forks source link

[Question] Content and quality of SBOMs #52

Closed MasahiroDAIKOKU closed 1 year ago

MasahiroDAIKOKU commented 1 year ago

Question

In some cases, SBOMs are generated using fee-based SCA tools, and in other cases, SBOMs are generated using open source software-based tools. Is it currently possible to keep the content and quality of the SBOM completely constant, independent of the tool or software used to generate the SBOM?

Suggested Solution

If it is practically difficult to keep the content and quality of the SBOM constant, we think that one approach is to state the following with regard to the tool generating the SBOM.

In this case, we think that an option to provide these information of the tool or software used to generate the SBOM should be defined using a field somewhere in the SPDX.

We would appreciate your comments.

vargenau commented 1 year ago

Hi Masa-san,

This is a good suggestion.

Let us discuss it in our next call.

Best regards,

Marc-Etienne

From: Masa DAIKOKU @.> Sent: Wednesday, May 3, 2023 5:39 PM To: OpenChain-Project/Telco-WG @.> Cc: Subscribed @.***> Subject: [OpenChain-Project/Telco-WG] [Question] Content and quality of SBOMs (Issue #52)

Question

In some cases, SBOMs are generated using fee-based SCA tools, and in other cases, SBOMs are generated using open source software-based tools. Is it currently possible to keep the content and quality of the SBOM completely constant, independent of the tool or software used to generate the SBOM?

Suggested Solution

As the content and quality of the SBOM depends on the tool or software generating the SBOM, if it cannot be kept constant at present, one option would be to state the following with regard to the tool generating the SBOM

In this case, we think that an option to provide these information of the tool or software used to generate the SBOM should be defined using a field somewhere in the SPDX.

We would appreciate your comments.

— Reply to this email directly, view it on GitHubhttps://github.com/OpenChain-Project/Telco-WG/issues/52, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAC4KKRPQDLVWQSXHLP5G6TXEJ32JANCNFSM6AAAAAAXUS3KWM. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

Jimmy-ahlberg commented 1 year ago

This seems like a very good idea to me. In case I'm not able to make next call I would like to add my support here.

stephenkilbaneadi commented 1 year ago

While I think this is a great idea, it is dependent on the SBOM-generating tool providing the content, or requiring post-generation edits. If a commercial tool doesn't already provide this information (which, IMO, every SBOM generator should provide), they may require some convincing to adopt this.

If SPDX-3.0 doesn't already require this, maybe this is feedback we can provide. :-)

MasahiroDAIKOKU commented 1 year ago

@vargenau @shanecoughlan @Jimmy-ahlberg

Thank you very much for your good feedbacks.

We have not actually compared the content and quality of SBOM created with OSS-based SCA software with the content and quality of SBOM created with paid-for SCA software, due to cost and human resource limitations.

In fact, the SCA software market is growing and we assume that the content and quality of SBOM will be a concern in the future. Poor quality SCA software may also be available on the market.

If you could support us in proposing this as a requirement for SPDX-3.0 or later, we would be grateful for your support.

Masa

Jimmy-ahlberg commented 1 year ago

I think this would make a great additions for SPDX 3.X. Happy to support that.

In the meantime we could perhaps add it to the specification here to show the SPDX community how it would work?

Without going into the details, we use a few SCA tools internally, both paid and free, they all have their respective strengths and weaknesses, having the information about the tool used to generate the SBOM would be useful. I assume that there is at least some "security" aspect to this information as well, in case it turns out a certain SCA tool of a specific version consistently missed certain pieces of software for whatever reason. That would be very good to know if one got a SBOM generated by that SCA tool of that version.

MasahiroDAIKOKU commented 1 year ago

@Jimmy-ahlberg

Thank you for your response. I completely agree with your comment that we should add to this Telco SBOM Spec. document what we require regarding SBOM generation tools.

As you pointed out, requesting this information would also contribute to the security of the overall system developed using the OSS. Do you have any other ideas of what to require in addition to following three points I suggested in my first post?

And, thank you for the very useful feedback from your real experience. If we have difference between SBOMs generated by using fee-based SCA tools and ones generated by using open source software-based tools, I think we may have to understand the following points at least.

In order to realize these thoughts, the following ideas, apart from the preparation of this document, might be necessary.

MasahiroDAIKOKU commented 1 year ago

@stephenkilbaneadi

As you pointed out, I also think commercial SBOM generation tools do not yet provide these information I raised. Also, it may take some persuasion for the SCA development vendors to adopt these points.

It may be optimistic, but if the SCA development vendors can embed their company name and the name of their SCA tool in SBOM data format, there may be advertising and promoting effects there. If the SCA development vendors considers that there is huge advertising and promoting effects for SCA company's marketing prospective, it might lead to a smooth adoption of the commercial SCA tools.

I think that it would be an option to add the above points to this document to verify if this effect exists.

While I think this is a great idea, it is dependent on the SBOM-generating tool providing the content, or requiring post-generation edits. If a commercial tool doesn't already provide this information (which, IMO, every SBOM generator should provide), they may require some convincing to adopt this.

If SPDX-3.0 doesn't already require this, maybe this is feedback we can provide. :-)

vargenau commented 1 year ago

Thank you all for your comments.

If we want to include the following in the Telco SBOM:

it can be done in the SPDX Creator field.

The Creator field is mandatory, it can contain one or more lines of the form:

"Person: person name" and optional "(email)"
"Organization: organization" and optional "(email)"
"Tool: toolidentifier-version"

So we can make it mandatory to have:

The SPDX standard gives "toolidentifier-version" as an example, but it is not mandatory to have this syntax. For example, there is a tool that outputs:

Creator: Tool: sigs.k8s.io/bom/pkg/spdx

We have also:

Creator: Tool: scancode-toolkit 30.1.0

and

Creator: Tool: SCANOSS-PY: 1.5.1

where the name contains an hyphen, and the tool name and tool version are not separated by an hyphen.

So I do not think we can require a precise syntax.

Let us discuss the details in our next call.

CsatariGergely commented 1 year ago

@MasahiroDAIKOKU OpenSSF has an SBOMs are everywhere WG with the aim to compare SBOM generators.

MasahiroDAIKOKU commented 1 year ago

@CsatariGergely Thank you very much for your very useful information. Is the following link the document you mentioned? Very interesting. https://docs.google.com/document/d/1UeV0BhZHKBIJY8fi40hAly3jP_dH9u7Nao4Alw8fY0Y/edit#

MasahiroDAIKOKU commented 1 year ago

If possible, please provide examples of creator field descriptions in the following cases in order to ensure correct understanding.