Dick, Precisely! If you want to know whether a Package contains a File that has a vulnerability, the Package Element IRI must be sufficiently specific. Using CONTAINS relationships to list the files in a package does not guarantee that specificity. That is the problem; it has nothing to do with where in the list a file appears.
Regards, Dave On Wed, Jan 19, 2022 at 9:08 AM Dick Brooks < [email protected]> wrote: > I agree, Dave. This is one of the reasons the NTIA Framing group > identified a tuple containing > SupplierName+SupplierProductName+ProductVersion to uniquely identify a > component. > > > > An SBOM for Zantac V1 would be different from an SBOM for Zantac V2, using > your analogy. In either case, does the consumer need to know where > ranitidine lies within the formula for Zantac, or just the fact than > ranitidine is present in the product? > > In the C-SCRM use case, it’s enough to know that ranitidine is present, or > not. > > > > > > Thanks, > > > > Dick Brooks > > *Never trust software, always verify and report! > <https://reliableenergyanalytics.com/products>* ™ > > http://www.reliableenergyanalytics.com > > Email: [email protected] > > Tel: +1 978-696-1788 > > > > *From:* David Kemp <[email protected]> > *Sent:* Wednesday, January 19, 2022 8:55 AM > *To:* [email protected] > *Cc:* SPDX-list <[email protected]> > *Subject:* Re: [spdx-tech] Relationships, properties, and syntactic sugar > > > > Dick, > > I used to take Zantac, which contained ranitidine, which turned out to > have problems. Now there's something *called* Zantac that doesn't have > ranitidine. Perhaps if enough people developed peanut allergies, Mars > would release something called "Snickers" but had cashews (a tree nut) > instead of peanuts (a legume) and wouldn't trigger peanut allergies. > > My point is that if there is a Zantac v1 and a Zantac v2, or a Snickers v1 > and Snickers v2, it's important for the consumer to know which is which. > Using a relationship is bad if it attempts to change the content of a > package. Properties inherently cannot change, so Element IDs must be > version-specific. But if you use relationships to represent the > ingredients of "Snickers" without specifying the version, the consumer > can't tell whether what's on the shelf is safe or not. > > Dave > > > > On Wed, Jan 19, 2022 at 8:01 AM Dick Brooks < > [email protected]> wrote: > > Dave, > > > > As Kate will tell you, I’m not a SBOM big picture guy, I > focus on the use of SBOM in a very narrow niche, software supply chain risk > assessments following NIST SP 800-161 Appendix F (EO 14028 implementation > guidelines), called C-SCRM. > > > > In a C-SCRM risk assessment, the relationship of components > isn’t as important as the software contents “SBOM ingredients list” that’s > used to search for vulnerabilities. > > > > To use an analogy, a snickers bar contains peanuts, which > someone with a peanut allergy needs to know, regardless of how it’s > constructed. The maker of snickers bars absolutely must know the > relationship of peanuts and all of the other ingredients, in the same way > that a software needs to know how the component pieces fit together. > > > > The discussion of relationships is germane to software vendor product > construction, but I don’t see this information being needed for a C-SCRM > risk assessment because the question being asked is “does a component have > vulnerabilities”, regardless of where it was implanted in the construction > of a software package. There are other factors that a software consumer may > want to know, i.e. provenance and pedigree of a component. > > > > Just my .02 > > > > Thanks, > > > > Dick Brooks > > *Never trust software, always verify and report! > <https://reliableenergyanalytics.com/products>* ™ > > http://www.reliableenergyanalytics.com > > Email: [email protected] > > Tel: +1 978-696-1788 > > > > *From:* [email protected] <[email protected]> *On Behalf Of > *David Kemp > *Sent:* Wednesday, January 19, 2022 7:17 AM > *To:* SPDX-list <[email protected]> > *Subject:* [spdx-tech] Relationships, properties, and syntactic sugar > > > > Gary observed that when using RDF serialization, reasoning about > relationships is significantly more difficult than reasoning about > properties. But that is not a serialization problem, it is just a symptom > of a model problem that applies to all serializations. > > The most basic question a logical model must answer is: "Does an Element > have a well-defined value?", or "Given an Element, what is its value?" If > an Element does not have a fixed value, then it is not hashable, and we > agreed long ago that Elements are immutable. > > The logical model must make it possible to answer the question "Does > Package X CONTAIN File Y" regardless of serialization. If Microsoft > creates Package Element X and defines it to contain File Elements 1, 2, 3, > and Acme creates a Relationship Element saying Microsoft's Package Element > X CONTAINS File Element 4, it is not a valid question to ask "Does Package > X CONTAIN File 4?" The question doesn't make sense and cannot be reasoned > about. The only valid questions are "Does Microsoft's *description* of > Package X at 15:34 on Tuesday contain File 4", and "Does Acme's > *description* of Package X at 19:23 on Wednesday contain File 4". The > answer to the first is a definite No, and to the second a definite Yes. > > Microsoft can create various Elements describing Package X at various > times with different contained files. One Package Element can list Files > 1, 2 and be marked "incomplete", but that is a different Element from one > that lists Files 1, 2, and 3 whether marked "incomplete" or not. So using > properties as syntactic sugar for relationships is valid ONLY when the > relationship and its "from" Package Element were minted together, i.e. have > the identical creation info. Relationships created 1 second after the > Package are not syntactic sugar for properties of that Package, they could > only be sugar for properties of a different Package Element created 1 > second after the first. > > > > The Package Element IRI must conceptually depend on the package's > major/minor/patch number, commit ID etc., if the files contained in the > package are different. > > So I would say it's a best practice to NOT duplicate properties with > relationships, because allowing them requires desugaring relationships into > properties based on identical creation info. If the practice isn't > forbidden you'll always have to deal with explaining "Acme's description of > Microsoft's package X as it existed at this point in the build chain". > > Dave > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4313): https://lists.spdx.org/g/Spdx-tech/message/4313 Mute This Topic: https://lists.spdx.org/mt/88532578/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
