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
<https://reliableenergyanalytics.com/products> Never trust software, always
verify and report! ™
<http://www.reliableenergyanalytics.com/>
http://www.reliableenergyanalytics.com
Email: <mailto:[email protected]>
[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 (#4310): https://lists.spdx.org/g/Spdx-tech/message/4310
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]]
-=-=-=-=-=-=-=-=-=-=-=-
