Skip to content

Latest commit

 

History

History
82 lines (77 loc) · 7.05 KB

2022-03-02.md

File metadata and controls

82 lines (77 loc) · 7.05 KB
Raw

SPDX Defects Team meeting - 2nd March 2022

Attendees

  • Rose Judge
  • Christian Long
  • VM Brasseur
  • Nisha Kumar
  • Dick Brooks
  • Karsten Klein
  • Jeff Schutt
  • Henk Birkholz

Agenda

  • General
    • Approval of minutes of last week's meeting
  • Adding linking to security vulnerability information in SPDX 2.3
  • Changing SPDX 2.x to enable SBOM without licensing fields to solely support security use cases

Notes

General

  • Approval of minutes of previous meetings:
    • Feb 23 meeting: spdx#131 -> ,
      • Please review & approve so we can merge
      • Rose proposes just merging the minutes after each call. Are people reviewing these otherwise?
      • VMB - open a PR, send an email, next meeting ask if there are any problems, if not merge at the beginning of the call. If not there are some antitrust issues that may arise.
      • Rose - what about meetings from two weeks ago.
      • VMB - you can say if nobody has problems for the two weeks worth of meetings.
      • Jeff - should we review the pending meeting minutes now?
      • Rose - Lots to discuss today, having folks review on their own time is more time effective
        • Consensus is to go ahead with VMB's proposal
      • Feb 16th meeting: spdx#129 -> if no comments merge by March 3rd?
      • Who will take minutes for today's meeting?
        • Nisha

Adding linking to security vulnerability information in SPDX 2.3

  • Proposal: https://docs.google.com/document/d/1A9lOwYrpVlmxBl_cEahZTMeo0gU6yDxkgSbx4I5K5v4/edit
  • Dick - CSAF is one option but there are others such as CycloneDX. We don't want to limit ourselves to one solution
  • Rose - CSAF would be one option that could be linked to, but the type would be a url. Any url would suffice.
  • Jeff - concur. There are use cases for commercial and open source software and we should be able to accomodate both.
  • Dick - had submitted proposed language last week.
  • Rose - We saw that github issue and updated the title at last weeks meeting: spdx/spdx-spec#627 (comment)
  • Dick explains
    • Identify "type" of security artifact
    • Identify the URL of the artifact (SBOM)
    • "What is the vulnerability status of product P, version V from Supplier S at time(NOW) at the SBOM component level?"
  • There was a request from Karsten to provide an example showing how option 1 would be manifested in an SBOM to answer the question: "What is the vulnerability status NOW of Product P, Version V from Supplier S, at the SBOM component level?
  • Dick - security object has to have a type
  • Rose - my preference is option 2 to capture the nuance of the link
  • Dick - the vuln status is explained in the URL (explains here: https://github.com/rjb4standards/REA-Products/blob/master/CDXVEX/CDX14.xml)
  • Nisha: why not just provide "vuln status" as an ExternalReference type
  • Dick: yes, we could do that.
  • Dick: CycloneDX uses an "implied trust" report and a more detailed report. In the detailed report, there will be a list of components whether a vuln is found or not. Both these types of reports can be accomodated.
  • Jeff: existing Security type has 2 types (cpe23 and cpe22) , and the proposal is to add more types such that all the OSV Reference Field types https://ossf.github.io/osv-schema/#references-field are consolidated? (Rose: yes). Jeff: So sounds like there is good compatibility with OSV.
  • Jeff: what about the CSAF types? Types need to match all the use cases.
  • Rose: If we want to be compatible with any and all standards, instead of just OSV, probably need option 1 which is just the URL. Although the nuance in option 2 having multiple types would be nice.
  • Option 1 is using the two CPE types and a new type called url which may be an advisory or something else.
  • Dick: but that would mean creating a lot of introspection code to collect that data for client tools.
  • Jeff: but there is complexity in replicating the data in the VEX document and the external reference.
  • The generic URL link could be anything, but at least there could be some determinism on whether the doc is an authoritative or informational document [with option 2].
  • Rose: how do we provide some nuance [for client tools who use the type category] without replicating the data?
  • Jeff: Perhaps we need to collect more user stories
  • Rose: what types does CycloneDX use? Dick: specifically identifies the types of vulnerabilities.
  • Henk: use cases - SBOMs updated over time based on release, then I would like to have the SBOM point to vulns that were resolved. Rose: so we need a type "resolved"? Henk: yes, most obvious solution.
  • Rose: "status" and "type" feels like two different fields?
  • Dick shows CDX vuln - will send email with that information.
  • Dick: Prefers option2; Option 2 is close to CSAF "category" https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/prose/csaf-v2-editor-draft.md#3213-document-property---category
  • Karsten: it would help more if I could take SBOM and accurately identify components and then check for vulns. So for this use case I only need a subset of use cases. There is an opportunity to start at option 1 and then improve in 3.0. Why should we duplicate the work in non-formatted data.
  • Karsten - if this is a sequence then multiple documents and updatable links would provide better lifecycle management.
  • Jeff: if we have a category called "security" and we want to identify "status", is the "status" more about the stage in the lifecycle of the process?
  • Karsten - in practice, there are multiple products there are different statuses.
  • Jeff - status of the vuln with respect to the component and its context
  • NVD - identifies vulnerable products based on product name and version tuples. In a static SBOM the correlation phase is offloaded to the supplier. You could have a link including the CPE, the CPE, or an authority that will list it for you. So we are looking for "vuln identifiers"
  • Jeff - we can use multiple external references. While there are a lot of security metadata and we can address it using external references, but we still don't have something that says "status" of "product".
  • Karsten would like a formal specification for.
  • Supplier build software using open source components. Collects info from advisories, then make assessments on exploitability, it also means talking about impact, this is the info that gets communicated to the customer.
  • Rose - wWe are out of time today, let's continue the conversation next week. Action is to bring more use cases for option 1 or 2 so we can move closer to a decision.

Changing SPDX 2.x to enable SBOM without licensing fields to solely support security use cases

  • From last week meeting => Thomas: Raised this in yesterday's tech call but wanted to also discuss it here - does this group agree to put in an issue to request a change to SPDX 2.x spec to make all license related fields optional?
  • Did not have a chance to discuss this. Push to next week.