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

RE: Updated User Scenarios Document



Thanks Philippe-Emmanuel, for turning these around so quickly! I took a quick look and will look closer later today or tomorrow.

 

From: Philippe-Emmanuel Douziech
Sent: Thursday, October 24, 2019 4:26 AM
To: Subject: RE: Updated User Scenarios Document

 

Hello again

 

I’ve now started to update the User Scenarios document, with hyperlinks to SBOM files (formatted as JSON and XML), for the Identity User Scenario.

 

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: jeudi 24 octobre 2019 09:47
To: Subject: RE: Updated User Scenarios Document

 

Hello

 

Regarding the current version of the proposed model, before addressing the illustration of the user scenarios from the user scenarios document, I wanted to share and explain the illustrations of the ways the current version of the proposed model can handle hierarchical / multi-level-of-granularity / need-to-know situations.

 

Starting from the same delivery (the multiple files from my tooling), I can

  • Produce 1 standalone SBOM,

o   named “”,

o   stored in 1 single physical file https://drive.google.com/open?id=1QvRq68o9woludq2_CLYFpmauwPCzwTma (JSON format) or https://drive.google.com/open?id=1eyzswgGn-VJZJgxaEZTDMHRf6F2rTbgm (XML format),

o   detailing the delivery of 9 files (3 R sources, 2 DOCX file, 2 PNG images, 2 XMI file)

  • Produce

o   1 wrapper SBOM,

§  named  “” (note that the name is identical as I deliver the exact same thing, I didn’t alter the files nor packaged them in a zip …),

§  stored in 1 single physical file https://drive.google.com/open?id=1SSgs92QKQCrvUnQiPZduB-N2MWrxp-mn (JSON format) or https://drive.google.com/open?id=1ZSBKV7YfQFyBFtsKzuNDuteZpt433aG1 (XML format) ),

§  detailing the delivery of the very same 9 files (3 R sources, 2 DOCX file, 2 PNG images, 2 XMI file)

o   9 detailed SBOM,

§  1 for the file buildXMI.R,

·         named ,

·         stored in 1 single physical file https://drive.google.com/open?id=1pQW5-StIV6o2aGqti5XC8sASgd280UC- (JSON format) or https://drive.google.com/open?id=1hFzIgg_1IIWxW5UBYv3WJ6L0OiaRiQyB (XML format)

·         detailing the buildXMI.R file

§  etc.,  

o   the link between the wrapper SBOM and the detailed SBOM is done via 9 relationships

§  such as
<relationship>
<relationshipType>relationshipType_packageOf</relationshipType>
<relatedDocument> </relationship>
in the XML format, where the relatedDocument points to the unique ID

  • Produce the same wrapper SBOM, the same detailed SBOM, with the same relationships,

o   stored in 1 single physical file https://drive.google.com/open?id=1cCzy_mfA996KV3kjLJ2h8OG6qVpZLw3W (JSON format) or https://drive.google.com/open?id=1L-7NGzTMKu-Kn03o25x_HhXh1RBWoyp1 (XML format)

o   the link between the wrapper SBOM and the detailed SBOM is done via the very same relationships, even though they are stored in the same physical file, database, …

 

Some comments

  • regarding the vulnerability analysis,

o   the vulnerability database would be able to refer the SBOM unique ID (replacing/complementing CPE and other identification),

o   and, assuming this artifact is re-used somewhere else, I’ll be able to track the chain of transformation

o   it’s a matter of which level of details I require from my supplier.

  • regarding the IP analysis,

o   the standalone SBOM and the wrapper SBOM would have an SPDX licensing _expression_ that expresses the mix of licenses (so no information about unwanted licenses is missing)

o   the detailed SBOM would have an SPX licensing _expression_ at the file level

o   so, again, it’s a matter of which level which level of details I require from my supplier

  • regarding the provenance analysis, there is no limit in terms of chaining the SBOM together (be they physically store in one file, many files, one database, many databases, …)
  • regarding the pedigree analysis, there is still no limit in terms of provenance chaining and in terms of link structure (it may not be a tree-like structure, as illustrated by the in-toto simple flow presentation in Nashville, TN)
  • regarding the identity, I created the wrapper SBOM because it had a meaning for me (my tooling); otherwise, I could have limited myself to individual SBOM; I could create any number of wrapper SBOM depending on what I’m delivering

 

I hope this helps,

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

 

 

Hi all,

 

I updated the user scenarios document following our meeting with a goal to capture (and in some cases further) our discussion.

 

Please have a look and share thoughts, feedback and questions.

 

I pushed the meeting along rather quickly today to keep us moving in our short time together.  Let’s have continued discussion over email, or feel free to suggest side meetings to cover topics in more detail.  All suggestions are welcome!

 

We are a team, let’s collaborate and learn – for the benefit of a higher-quality, more secure software ecosystem.

 

Thanks!

Kay