Technical Team/2018-12-4

From SPDX Wiki
< Technical Team
Revision as of 18:23, 18 December 2018 by Goneall (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

December 4, 2018


  • Gary O'Neall
  • James Neushul
  • Alexios Zavras

SPDX Model Updates for SEVA fields

  • Discussed the vulnerability relationship to SpdxItem, Package, and File
    • Most vulnerabilities will be associated with package
      • NIST NVD’s can only be associated with packages
    • There are some scanners that will associate vulnerabilities with files
    • Agreed that we should associate the vulnerability to Item so that it can apply to both Package and File
    • vulnerability information is optional (0 to many)

SEVA Vulnerability inclusion in SPDX

  • Most of the information is based on the NIST NVD definitions
    • Modeled after the definition documentation
    • A schema for the NVD which includes all of the details (e.g. scoring) does not exist (or at least we could not find one)
    • Names do not match the NVD names to support distinguishing an official NVD schema if one to be found or produced
  • Reviewed the SPDX-SECURITY schema at
  • There is also an SPDX-SEC-ISM schema which includes classification information (ISM)
    • We agreed that the ISM information would be valuable to commercial use, but can be a separate decision from the vulnerability information
  • Discussed whether we should include all of the detail present in the SEVA document in the SPDX document or should we somehow reference an external document
    • There are a large number of fields to be reviewed
    • We are not vulnerability experts, and may not have the background to decide on a model and tools of our own
    • Agreed we should reference an external document
  • We agreed that the vulnerability information should be included
  • We discussed having a “proposal” or “working draft” similar to the W3C for the external document

Next Steps in Vulnerability inclusion in SPDX

  • Gain a larger consensus on referencing an external document for vulnerabilities
  • Draft the external document reference language
  • Discuss / agree on the external reference content