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

RE: [EXT] Artifact, or Element, or Package



Hello again,

 

I’ve posted a second example https://drive.google.com/open?id=1SSgs92QKQCrvUnQiPZduB-N2MWrxp-mn

It illustrates the split approach when detailed information about each file is needed.

 

Compared to the single-package approach (https://drive.google.com/open?id=1QvRq68o9woludq2_CLYFpmauwPCzwTma ), the only differences are:

  • The existence of 1 SBOM per file
  • The reference to these SBOM files from the wrapper SBOM file

The wrapper SBOM file still details a multi-file artifact as I’m delivering distinct files and not a zip file containing the individual files.

 

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: mercredi 23 octobre 2019 09:44
To: Kay Williams Ido Green Dan Lorenc Cc: Martin, Robert A. Subject: RE: [EXT] Artifact, or Element, or Package

 

Hello

 

About Which of the following do we do?" , the model right now lets you do 1. and 2.

The decision between the 2 options should be driven by the way you use these artifacts and the overhead you’re willing to pay:

  • Assuming you have 1 SBOM per file and 1 wrapper SBOM, it’s easy to reuse any one of the files individually in any other artifacts, as these new artifacts will get new wrapper SBOMs reusing the file-level SBOM
  • Assuming you have 1 SBOM per license type and 1 wrapper SBOM, using only 1 file from the license-type-level SBOM would require you to create a new SBOM for this file

In my opinion, it’s similar to the source repository discussion: the specification supports 1 SBOM for the whole source repository (1 artifact but many many files) and the specification supports 1 SBOM per file in the source repository and 1 wrapper SBOM for the repository if needed

 

About 3., the model as of now would deal with the situation the following way: the LicenseInfo is based on a licensing _expression_ which can indicate that you are using multiple licenses.

Would you or your supplier/customer need finer-grain information, then you would provide the information as described in 1. and 2.

In my opinion, it’s similar to the Windows discussion: you may not disclose file-level information about the distribution of Windows, but, if you choose to or are required to do so, you should comply with the 3T-SBOM-EMS format.

When you write “I say this because the file is the level of granularity at which we want to attach intellectual property (license) data.”, it means you “choose to or are required to do so” and you are willing to pay the overhead to attach the information at the file-level.

 

By the way, I posted an illustration of the proposed model with my tooling in the google drive: https://drive.google.com/open?id=1QvRq68o9woludq2_CLYFpmauwPCzwTma

It’s multi-file but single-SBOM.

 

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. I have been working through some examples in our User Scenarios document and have a question related to the multiplicity of files.

 

Specifically, I wonder if it might be better to have a 1:1 relationship between an SBOM and a single artifact file. I say this because the file is the level of granularity at which we want to attach intellectual property (license) data.

 

Let’s say we have three files, a, b and c. Files a and b are GPL licensed., File c is BSD.

 

Which of the following do we do?

 

  1. Files a, b, and c each have an associated SBOM, in addition there is a wrapper SBOM that has ‘contains’ relationships with SBOM_A, SBOM_B, and SBOM_C.
  2. Files a and b have an associated SBOM. File c has an associated SBOM.  In addition there is a wrapper SBOM with ‘contains’ relationships to SBOM_A&B, SBOM_C.
  3. Modify our model so that licenseinfo can be carried on the file element, and all files can be described in a single SBOM
  4. Something else.

 

Am I understanding our current model correctly?

 

Thanks,

Kay

 

 

Hello everyone

 

As you can guess from my first model, I'm also in favor of Artifact.

About the multiplicity of files, the model is quite clear with a [1..*] cardinality between the Artifact class and the File class.

To help, we could make sure that every illustrations of the different usage scenarii are multi-file situations.

 

For your information, I posted updated versions of the documents (docx, pdf, xmi) and illustrations in the SBOM google drive; they contain:

* Artifact terminology 

* optional association between the Document class and the LicenseInfo

 

Philippe 

 


+1 for artifact 

But I wonder how can we make it clear that it could contain multiple files.

 

I like artifact as well. I acknowledge that it has the implication of only a single entity, but I think it's still our best option. We should make it clear that a "logical artifact" can refer to multiple files.

 

Dan Lorenc

 


Hi all,

 

Here is another nomenclature question for our group.  I was talking with Kate Stewart (Linux Foundation, SPDX) this afternoon. We were discussing what to call the ‘target’ or ‘object’ of an SBOM.  In other words, what is the ‘thing’ an SBOM describes. We think the ‘thing’ is broad, where it may span the following:

 

·         File diff

·         File

·         Commit, File Archive, Package, Container (all of which span multiple files)

·         File System, Cloud Service (all of which span multiple packages, containers, etc.)

 

Kate mentioned that in SPDX today the ‘thing’ is an ‘element’. (Not a ‘package’ – Philippe-Emmanuel, we may have been mapping to the wrong SPDX element).

 

I propose that for the SBOM we call the ‘thing’ an ‘artifact’. This has the following implications:

 

  1. SPDX 3.0 would need to rename the ‘element’ field to ‘artifact’.
  2. Philippe-Emmanuel would need to update the SBOM model to center around the term ‘artifact’.

 

Does this work? Thoughts?

 

Kay