I agree with William. Providing underlying supply chain information would enable a software vendor to create a “CSAF Security Advisory” listing products which ARE affected by a vulnerability OR a “CSAF VEX” listing products which ARE NOT affected by a vulnerability. Keeping it abstract enables a software vendor to choose to express the vulnerability from a POSITIVE or NEGATIVE perspective.
A NIST VDR is “product centric”, listing the vulnerability status for each SBOM component within a single software product. 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-defe...@lists.spdx.org <spdx-defe...@lists.spdx.org> On Behalf Of William Bartholomew (CELA) via lists.spdx.org Sent: Monday, April 17, 2023 5:43 PM To: 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 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 (#5089): https://lists.spdx.org/g/Spdx-tech/message/5089 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] -=-=-=-=-=-=-=-=-=-=-=-
