You will also need to identify which VEX format to serialize, CSAF VEX, CycloneDX VEX, Open VEX or CISA VEX (publication coming)
Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: <mailto:d...@reliableenergyanalytics.com> d...@reliableenergyanalytics.com Tel: +1 978-696-1788 From: Spdx-tech@lists.spdx.org <Spdx-tech@lists.spdx.org> On Behalf Of Sean Barnum Sent: Monday, April 17, 2023 6:30 PM To: will...@microsoft.com; spdx-defe...@lists.spdx.org; Spdx-tech@lists.spdx.org; g...@sourceauditor.com Subject: Re: [spdx-defects] [spdx-tech] SPDX 3.0: When to use a property or relationship To the original query from Thomas requesting guidance on when to use a property vs a relationship, the general rule of thumb we have agreed to recommend is that if a relationship is inherent and immutable to its source object then it is most appropriate to utilize the simple object property option. Otherwise, it is more appropriate to utilize a Relationship object. I proposed this rule of thumb based on experiences in other ontology development efforts. If you want to see more detail on the hows and whys, you can look at section 6 on the UCO design document at https://unifiedcyberontology.org/resources/uco_design_document.html (you can obviously ignore references to UCO, specific properties, context of the examples, cardinality within UCO, etc. but the basic principles hold true for SPDX as well). For the specific vulnerability & VEX case, if I had to choose one of the options Thomas provided I would concur with David and Gary to choose #2. However, I am in strong agreement with William here that it seems much more appropriate for SPDX to focus on the underlying concepts like packages, vulnerabilities, relationships, etc to enable a VEX document to be derived from it rather than defining yet another format for a VEX doc. I agree with William that the core product status/exploitability values seem like excellent values (affects, does not affect, contains fix for, may affect (under investigation)) for relationshipType in Relationships from a Vulnerability to one or more Packages. These are for more flexible to support assertions by original producers, 3rd parties, updating existing assertions, etc. They also provide a clear picture for the derivation of a VEX doc. As William points out, it would be simple to then define a Bundle with a ‘context’ property of something like “VEX content” and simply reference all the packages, vulnerabilities and relationships. Sean Sean Barnum C – 703-473-8262 <mailto:sbar...@mitre.org> sbar...@mitre.org We are here to change the world! <https://www.facebook.com/MITREcorp> <https://www.linkedin.com/company/mitre> <https://twitter.com/MITREcorp> <https://www.youtube.com/user/mitrecorp> <https://plus.google.com/+MitreOrgFFRDCs/posts> <http://www.mitre.org/> From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org> <Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org> > on behalf of William Bartholomew (CELA) via lists.spdx.org <willbar=microsoft....@lists.spdx.org> Date: Monday, April 17, 2023 at 5:43 PM To: spdx-defe...@lists.spdx.org <mailto:spdx-defe...@lists.spdx.org> <spdx-defe...@lists.spdx.org <mailto:spdx-defe...@lists.spdx.org> >, Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org> <Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org> >, g...@sourceauditor.com <mailto:g...@sourceauditor.com> <g...@sourceauditor.com <mailto:g...@sourceauditor.com> > Subject: [EXT] Re: [spdx-defects] [spdx-tech] SPDX 3.0: When to use a property or relationship There is a fundamental question we need to answer first: are we trying to model VEX in SPDX or are we trying to model the underlying supply chain information and from that a VEX document can be derived? I'd suggest that we want to do the latter because it doesn't constrain how the underlying information is used. The VEX concepts of "affects", "does not affect", "investigating" are ones that map to relationships in my mind. Finding additional products (or versions of a product) affected by a vulnerability, or determining a product isn't affected, doesn't alter the underlying vulnerability. This is true for both vulnerabilities in the product itself, as well as vulnerabilities in third-party components used in the product. Additionally, I'd want the ability for people to create their own relationships to express additional products they believe are (or are not) affected by a vulnerability, in the same way that others can come to their own determination of licensing. In this model you could add or amend relationships over time expressing whether different products are or are not affected and at any time you could gather those up and export them as a VEX document. You could capture the list of relationships that was exported into a VEX document as a Bundle (or something that derives from Bundle) to make it easier to identify new ones or perform diffs at a later stage. William _____ From: Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org> <Spdx-tech@lists.spdx.org <mailto:Spdx-tech@lists.spdx.org> > on behalf of Gary O'Neall via lists.spdx.org <gary=sourceauditor....@lists.spdx.org <mailto:gary=sourceauditor....@lists.spdx.org> > Sent: Monday, April 17, 2023 1:47 PM To: spdx-defe...@lists.spdx.org <mailto:spdx-defe...@lists.spdx.org> <spdx-defe...@lists.spdx.org <mailto:spdx-defe...@lists.spdx.org> >; spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> <spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> > Subject: [EXTERNAL] Re: [spdx-defects] [spdx-tech] SPDX 3.0: When to use a property or relationship I’m thinking it would be common to discover additional elements affected by a vulnerability after a VEX is initially published which would cause the list of elements referenced to change. Therefore my vote would be for B. If it unlikely to change, I would agree with David a property would be better. Gary From: spdx-defe...@lists.spdx.org <mailto:spdx-defe...@lists.spdx.org> <spdx-defe...@lists.spdx.org <mailto:spdx-defe...@lists.spdx.org> > On Behalf Of David Kemp Sent: Monday, April 17, 2023 11:25 AM To: spdx-tech@lists.spdx.org <mailto:spdx-tech@lists.spdx.org> ; spdx-defe...@lists.spdx.org <mailto:spdx-defe...@lists.spdx.org> Subject: Re: [spdx-defects] [spdx-tech] SPDX 3.0: When to use a property or relationship As a general rule, properties are used when an element's content is known at the time the element is created, while either references or relationships are used when that content is expected to change over time. For example, a hypothetical "Person" element would include immutable properties of a specific person, but would not include a "child" property because children can pop up later. A Person element could include a parent property because parents don't change, and/or a "parentOf" relationship could be used to cover more dynamic possibilities like unknown or sealed biological parents that could be discovered or unsealed after the child instance is created. So if I understand the example, Option A should work since the status of a specific product with respect to a specific vulnerability should not change. And if it does change, a new VEX "urn:spdx.dev:vex-cve-2020-2849-2" will be issued to supersede "-1". But I'm not sure how "Our version of this package was modified" gets translated to "We are not using this component" with a "product" property. Are "we" creating a product that has the identical name, including version number, as a package (urn:npmjs.com:elliptic-6.5.3)? If so, how is the unaffected package or product distinguished from the original/unmodified baseline that presumably is affected by the vulnerablity? v/r, David On Mon, Apr 17, 2023 at 11:18 AM Thomas Steenbergen <opensou...@steenbe.nl <mailto:opensou...@steenbe.nl> > wrote: Hi all, In April 12th Defects meeting we were discussing changing the security profile <https://github.com/spdx/spdx-3-model/tree/security-profile/security-profile> to be better able to support VEX use cases. We ran into the reoccurring issue of when to use a property and when to use a relationship, included some examples below. Know we discuss this in a recent tech call. Do we have any written guidance/design principles? Can we discuss this further tomorrow? Below an excerpt of SPDX 3.0 Vulnerability example as currently found on GitHub, issue we found is that changing any VEX property would require publishing the whole vulnerability which is not ideal. Idea is to move VEX and maybe other categorization into their own elements so SPDX creator can update just the categorization and timestamp for each categorization creation using SPDX 3.0 Element's creationInfo. "@type": "Vulnerability", "@id": "urn:spdx.dev:cve-2020-2849", "summary": "Use of a Broken or Risky Cryptographic Algorithm", "description": "The npm package `elliptic` before version 6.5.4 are vulnerable to Cryptographic Issues via the secp256k1 implementation in elliptic/ec/key.js. There is no check to confirm that the public key point passed into the derive function actually exists on the secp256k1 curve. This results in the potential for the private key used in this implementation to be revealed after a number of ECDH operations are performed.", "modified": "2021-03-08T16:02:43Z", "published": "2021-03-08T16:06:50Z", "categorizations": [ { "@type": "VexNotAffectedVulnerabilityCategorization ", "@id": "urn:spdx.dev:vex-cve-2020-2849", "status": "notAffected", "impact": "Our version of this package was modified and does not include code affected by cve-2020-2849.", "justification": "vulnerabileCodeNotPresent", "source": "https://vex-system...";, } ], { "@type": "Relationship", "relationshipType": "advisory", "to": "urn:spdx.dev:vex-cve-2020-2849", "from": ["urn:npmjs.com:elliptic-6.5.3", "urn:npmjs.com:elliptic-6.5.3-subcomponent-1"] }, Option A: Only use properties to link a VEX to other SPDX elements - easy for VEX publishers and readers as everything is in 1element { "@type": "VexNotAffectedVulnerabilityCategorization", "@id": "urn:spdx.dev:vex-cve-2020-2849-1", "status": "notAffected", "impact": "We are not using this component", "justification": "componentNotPresent", "source": "https://vex-system...";, "elements": { "product": ["urn:npmjs.com:elliptic-6.5.3"], "packages": ["urn:npmjs.com:elliptic-6.5.3", "urn:npmjs.com:elliptic-6.5.3-subcomponent-1"], "files": ["urn:npmjs.com:elliptic-6.5.3-subcomponent-files-1"], "snippets": ["urn:npmjs.com:elliptic-6.5.3-subcomponent-snippet-1"], "vulnerabilities": [ "urn:spdx.dev:cve-2020-2849" ] } Option B: Specific property for vulnerability as VEX is always connected to one or more vulnerabilities, using relationships for linking to packages / "products", files, snippets as they may change. { "@type": "VexNotAffectedVulnerabilityCategorization ", "@id": "urn:spdx.dev:vex-cve-2020-2849", "status": "notAffected", "impact": "Our version of this package was modified and does not include code affected by cve-2020-2849.", "justification": "vulnerabileCodeNotPresent", "source": "https://vex-system...";, "vulnerability": [ "urn:spdx.dev:cve-2020-2849" ] }, { "@type": "Relationship", "relationshipType": "advisory", "to": "urn:spdx.dev:vex-cve-2020-2849", "from": ["urn:npmjs.com:elliptic-6.5.3", "urn:npmjs.com:elliptic-6.5.3-subcomponent-1"] }, Option C: Feel free to propose other ways .. Warm regards, Thomas -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5093): https://lists.spdx.org/g/Spdx-tech/message/5093 Mute This Topic: https://lists.spdx.org/mt/98329292/21656 Group Owner: spdx-tech+ow...@lists.spdx.org Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
