[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Review of the SBOM Object Model



Hello all,

 

Here follow my thoughts:

  • About the multi-package suggestion: still with the goal to keep the model as simple as possible, what about the following modeling of the use cases you described:
    • Patch file for an external package:  SBOM#1 details a package defined by the one file, the component named “patch xyx package”, its version, and its hash; this SBOM#1 has a relationshipType_patchFor relationship to SBOM#2 documents, which is the SBOM for the external package
    • Composition of a package: SBOM#1 details the package of package defined by the files the package of packages is composed of, the component named “packagage of packages”, its version, its hash; this SBOM#1 has relationshipType_contains relationships to the SBOM#i.. documents, which are the SBOM for the packages packaged as a single package
  • About the licensing information: I can make it optional; I modeled it according to the discussions from the workshop but I may have misunderstood that part; I thought we wanted to push for licensing information all the time
  • About the relationship association: it indeed depends on the first item

Let me know your thoughts,

 

Philippe-Emmanuel Douziech
Principal Research Scientist, CAST Research Labs

M: +33 6 69 95 49 59

CAST | Software Intelligence for Digital LeadersBlog | LinkedIn | Twitter

 

From: Philippe-Emmanuel Douziech
Sent: samedi 19 octobre 2019 12:15
To: Gary O'Neall Cc: Kate Stewart Kay Williams Subject: Re: Review of the SBOM Object Model

 

Hello and thank you for the input, I’ll look into it early next week...

Have a good weekend,

Philippe-Emmanuel Douziech 
Principal Research Scientist, CAST Research Labs

M: +33 6 69 95 49 59

CAST | Software Intelligence for Digital Leaders | Blog | LinkedIn | Twitter



On 18 Oct 2019, at 21:13, Gary O'Neall <



Hi Philippe-Emmanuel,

 

I went through some of the modeling documents you provided on Google Drive.

 

Overall, the model looks good and I appreciate how well it aligns with the SPDX model.  There are a few understandable differences in terms, but those are mostly in abstract classes that would not be represented in a concrete Document. 

 

I do have a couple of suggestions based on our experience in the SPDX modeling:

 

  • Support for Multiple “Items” within a Document:

 

The current SBOM mobile has a 1:1 relationship between a Document and a Package.  I would propose a structure which allows multiple “Items” to be represented within a single document.  An Item would be a superclass of both Package and File.  A Document would have a 1 to many relationship to Items.  Item would be a subclass of Element.  This would be similar to the SpdxItem class in the SPDX Model.  Note that in the SPDX model, SpdxItems are referenced by the SpdxDocument through the relationship properties in the SpdxElement superclass.  Another note on SpdxItem – it currently contains a number of required licensing related properties.  In the 3.0 spec, these properties will most likely become optional and some additional security related properties added to enable support of security related use cases without the burden of adding licensing information.

 

It turns out version 1.0 of SPDX had a 1:1 relationship between a Document and a Package.  As we gained experience in using the SPDX Document, we found several use cases which required a more flexible structure.  As an example, we wanted to have an SPDX Document which just described a patch file which patched a package.  The package definition was external to the document.  Describing a single file in an SPDX Document wasn’t possible in our 1.0 version.  Another common use case was wanting to describe the composition of a package within the same document.  This required multiple packages to be represented within the same document.  Note that the above examples would likely be just as important in a security related use case as it would be to a copyright license related use case.

 

  • Move relationships from the Document to Element:

 

If the above proposed change is made and there are multiple “Items” represented within a Document, providing relationships within the document itself would be important to support several of the use cases.  Moving relationships to Element would allow relationships between Packages, Files and Documents.

 

I will be traveling starting tomorrow, but I plan on checking emails approximately daily and would be happy to continue a dialog via email on the model.

 

Also – let me know if you would like to move this discussion to one of the documents in Google Docs.

 

Best regards,
Gary

 

-------------------------------------------------

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.