[Question] Clarification of the difference between the latest human readable SBOM and the previous delivered one

[MasahiroDAIKOKU]

Question

Section 3.6 describes when humans process SBOMs.

The SBOM is attached to the newly developed software when it is delivered to the customer. Considering agile development, the developed software may be delivered to the customer in every sprint in order to get feedback from the customer.

This may not be necessary when the SBOM is processed by a system such as an SCA tool, but considering the case where the SBOM is processed by humans, it is necessary to precisely and clearly indicate the difference between the latest SBOM and the previous one, from the perspective of human work efficiency.

Suggested Solution (optional)

It is very useful from the point of view of human work effectiveness to make explicit the difference between the latest SBOM and the previous delivered SBOM when the developer delivers the human-processed SBOM to the customer.

What do you think about adding a statement to section 3.6 to say that it is a requirement, an optional requirement or a recommendation that the differences be made explicit?

[Jimmy-ahlberg]

This is an interesting idea! I have some thoughts on it,

1. Should the diff only cover the latest version or always benchmark towards the earliest version delivered?
2. There is a risk for errors introduced in this process.
3. There are plenty of tools to do a diff of the information between versions, assuming its in the same format (that is in turn specified in the Telco SBOM Specification).
4. How do we mark that stuff has been removed? If something is added, that seems simple enough.
5. If we introduce this, how descriptive should we be in how things should be marked?

My proposal would be 1. Put this into the bucket of features to evaluate for the next version of the specification OR 2. Add it as an optional feature that could be referenced in a a purchase agreement for example.

[shanecoughlan]

TBH, I would hesitate to add this. My rationale is that we have a stance of defining what but not how with the the existing OpenChain specifications for license compliance (ISO/IEC 5230) and security assurance (ISO/IEC 18974). While the Telco Work Group "meta-spec" is not part of the same track as the ISO standards, I would worry that getting too granular would inhibit workflows. This is with awareness that workflows may not be optimal, but with the assumption that workflows should primarily be governed by industry-specific and company-specific contracts once the broad strokes are in place.

Example what:

Have an SBOM.

Example what + how:

Have an SBOM

The SBOM must / is recommended to include [ITEM1], [ITEM2], [ITEM2].

End

This is not to preclude this development! It might make a lot of sense in this context. I am just throwing these notes to @vargenau, @Jimmy-ahlberg and you to respond to the assignment to me with the start of this thread.

[CsatariGergely]

I think what we would need is some kind of a versioning of the SBOM-s of the same software and we should use the SBOM diff tools to generate the diff.

[Jimmy-ahlberg]

To some degree I feel that this is solved by the addition of the information about the SBOM tool used.

My thinking here is that as long as its being generated by the same SBOM tool/version I can trust the diff to be reasonably accurate. While if the SBOM is generated by another tool/version then the diff might not be accurate as we are no longer comparing apples to apples.

[vargenau]

If the SBOM if created manually, the creator should be able to tell the differences between current and previous SBOM.

But if the SBOM is created automatically by a tool, it might not be trivial to tell the differences; a Unix diff might give too many results if e.g. the packages are listed is a different order or if different identifiers have been generated by the tool.

So I propose to close this issue.

[MasahiroDAIKOKU]

Thank you very much for your reply comments.