[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review of the SBOM Object Model
Hello again
You're right; up to now, we were considering that the identifier would be the set { supplier, component, version, checksum } of the the package.
With multiple packages, we would have to come up with a package of packages, i.e., the modeling I proposed to support the use case.
Philippe-Emmanuel
________________________________________
From: William Cox
Sent: Monday, October 21, 2019 4:30 PM
To: Philippe-Emmanuel Douziech; Gary O'Neall
Cc:
Subject: Re: Review of the SBOM Object Model
Re: multi package documents
Would making this 1:m pose a problem for preserving the document signing checksums (if present)? Mixing multiple packages into a single document (if not the original document of the packages) would prevent the conveyance of the signing envelope.
--
William Cox
Senior Software Engineer
Synopsys – Software Integrity Group
-----Original Message-----
From: Philippe-Emmanuel Douziech
Date: Monday, October 21, 2019 at 03:49
To: Gary O'Neall
Cc:
Subject: 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.castsoftware.com_&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=FvHg29Cazexnu1QVm56OxrrBQ5fmDrTnCOx6evWMe78&e=>
| Software Intelligence for Digital Leaders | Blog <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.castsoftware.com_blog&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=ddSlk4XLmQPguWUYETVSR6z5ZRJpbeS5F_QYKukG3bA&e=> | LinkedIn <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_162909_&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=vaLl10tLCshHOhs-F8SI84H5L2HJyu7wc0W945vTE5g&e=> | Twitter <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_OnQuality&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=MjggKlsRGXYEeLmWIwpTb01i75EFn_SgjDqLHDazWIo&e=>
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 <tel:+33%206%2069%2095%2049%2059>
CAST <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.castsoftware.com_&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=FvHg29Cazexnu1QVm56OxrrBQ5fmDrTnCOx6evWMe78&e=> |
Software Intelligence for Digital Leaders | Blog <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.castsoftware.com_blog&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=ddSlk4XLmQPguWUYETVSR6z5ZRJpbeS5F_QYKukG3bA&e=> | LinkedIn <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_162909_&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=vaLl10tLCshHOhs-F8SI84H5L2HJyu7wc0W945vTE5g&e=> | Twitter <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_OnQuality&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=MjggKlsRGXYEeLmWIwpTb01i75EFn_SgjDqLHDazWIo&e=>
On 18 Oct 2019, at 21:13, Gary O'Neall wrote:
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.spdx.org_view_Technical-5FTeam_Model-5F2-5F2&d=DwMGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=D9GXZ0wCNDFAgxQ5YFiaQVGxI72cRHbU39Vj-PTrlAg&m=C8yDJQorn3aiTzkduTWjhM4Uvvv7YFfGZlpXPWL1lWc&s=-FkxUnO0J9irm3rx_EfKgOnh-7tjRv4eM8r-Maf7WSY&e=>. 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.