RE: Updated User Scenarios Document

[Philippe-Emmanuel Douziech <Date: Thu, 24 Oct 2019 07:47:10 +0000]

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,
  • named 3T-SBOM-EMS CRL tooling 23d172b3 md5:5ce3a428625a3ffa8b5d9bdf293cab1a sha1:62a5af236dfd664139e2ad1e5cf29ab72a3ee4c1 sha256:3f3699c3cfacf51c6bb5cda05050b7f56bd7e8e7a51f7836c7805c578627323c”,
  • 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),
  • detailing the delivery of 9 files (3 R sources, 2 DOCX file, 2 PNG images, 2 XMI file)
• Produce
  • 1 wrapper SBOM,
    • named 3T-SBOM-EMS CRL tooling 23d172b3 md5:5ce3a428625a3ffa8b5d9bdf293cab1a sha1:62a5af236dfd664139e2ad1e5cf29ab72a3ee4c1 sha256:3f3699c3cfacf51c6bb5cda05050b7f56bd7e8e7a51f7836c7805c578627323c” (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)
  • 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.,  
  • the link between the wrapper SBOM and the detailed SBOM is done via 9 relationships
    • such as
      <relationship>
      <relationshipType>relationshipType_packageOf</relationshipType>
      23d172b3 md5:4835e346c25de6f5975538c112b76ed0 sha1:37295350142273f88fc9cff1ba268c90e860f560 sha256:9308cea6e3b2ff68e6497d17858028100c23e2c15715cb6d96324a67be66d0cf</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,
  • 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)
  • 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,
  • the vulnerability database would be able to refer the SBOM unique ID (replacing/complementing CPE and other identification),
  • and, assuming this artifact is re-used somewhere else, I’ll be able to track the chain of transformation
  • it’s a matter of which level of details I require from my supplier.
• regarding the IP analysis,
  • 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)
  • the detailed SBOM would have an SPX licensing _expression_ at the file level
  • 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 Leaders | Blog | LinkedIn | Twitter

 

From: Kay Williams
Sent: jeudi 24 octobre 2019 01:27
To: Subject: Updated User Scenarios Document

 

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