RE: Review of the SBOM Object Model

[Philippe-Emmanuel Douziech <p.douziech@castsoftware.com>]

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 [WilliamE.Cox@synopsys.com]
Sent: Monday, October 21, 2019 4:30 PM
To: Philippe-Emmanuel Douziech; Gary O'Neall
Cc: sbom@omg.org
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 <p.douziech@castsoftware.com>
Date: Monday, October 21, 2019 at 03:49
To: Gary O'Neall <gary@sourceauditor.com>
Cc: "sbom@omg.org" <sbom@omg.org>
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 <p.douziech@castsoftware.com>

    Sent: samedi 19 octobre 2019 12:15
    To: Gary O'Neall <gary@sourceauditor.com>
    Cc: Kate Stewart <stewart@linux.com>; sbom@omg.org; Kay Williams <kayw@microsoft.com>
    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 <gary@sourceauditor.com> 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: gary@sourceauditor.com
    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.