https://wiki.spdx.org/index.php?action=history&feed=atom&title=Technical_Team%2FMinutes%2F2018-12-4 2026-05-07T12:25:48Z Revision history for this page on the wiki MediaWiki 1.23.13 https://wiki.spdx.org/index.php?title=Technical_Team/Minutes/2018-12-4&diff=4648&oldid=prev 2018-12-05T18:38:03Z

<p>Created page with &quot;December 4, 2018 == Attendees == * Gary O&#039;Neall * James Neushul * Alexios Zavras ==SPDX Model Updates for SEVA fields== * Discussed the vulnerability relationship to SpdxItem...&quot;</p> <p><b>New page</b></p><div>December 4, 2018<br /> == Attendees ==<br /> * Gary O'Neall<br /> * James Neushul<br /> * Alexios Zavras<br /> <br /> ==SPDX Model Updates for SEVA fields==<br /> * Discussed the vulnerability relationship to SpdxItem, Package, and File<br /> ** Most vulnerabilities will be associated with package<br /> *** NIST NVD’s can only be associated with packages<br /> ** There are some scanners that will associate vulnerabilities with files<br /> ** Agreed that we should associate the vulnerability to Item so that it can apply to both Package and File<br /> ** vulnerability information is optional (0 to many)<br /> <br /> ==SEVA Vulnerability inclusion in SPDX==<br /> * Most of the information is based on the NIST NVD definitions<br /> ** Modeled after the definition documentation<br /> ** 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)<br /> ** Names do not match the NVD names to support distinguishing an official NVD schema if one to be found or produced<br /> * Reviewed the SPDX-SECURITY schema at https://spdx-ccm.specchain.org/xsdccm/home<br /> * There is also an SPDX-SEC-ISM schema which includes classification information (ISM)<br /> ** We agreed that the ISM information would be valuable to commercial use, but can be a separate decision from the vulnerability information<br /> * 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<br /> ** There are a large number of fields to be reviewed<br /> ** We are not vulnerability experts, and may not have the background to decide on a model and tools of our own<br /> ** Agreed we should reference an external document<br /> * We agreed that the vulnerability information should be included<br /> * We discussed having a “proposal” or “working draft” similar to the W3C for the external document<br /> <br /> ==Next Steps in Vulnerability inclusion in SPDX==<br /> * Gain a larger consensus on referencing an external document for vulnerabilities<br /> * Draft the external document reference language<br /> * Discuss / agree on the external reference content<br /> <br /> ==Documentation for SPDX including SEVA==<br /> * James provided a document<br /> * Produced from the XML document<br /> * Extension to allow security classifications for each element (e.g. confidential)<br /> ** Uses ISM schema<br /> * Discussion on approach<br /> ** Document in sections vs get experience with proposed sections prior to specifying<br /> ** Document in sections first is the traditional approach for SPDX, may have “culture shock” switching to a more prototyping approach<br /> ** Danger in specifying first – may create implementation challenges and may create specs that are not widely used<br /> * Discussion on scope and prioritization<br /> ** Large scope – many new sections and properties<br /> ** Suggestion to prioritize by importance and ease of standardization<br /> * Discussion on the modeling<br /> ** Agreed modeling will be helpful<br /> * Plan going forward:<br /> ** Next week Mathew will review some of the new sections/areas being proposed and help prioritize which areas would be most useful<br /> ** Next week’s call will focus on the use cases / prioritization<br /> ** In 2 weeks, Gary will propose an update to the model which will include the higher priority areas/sections<br /> <br /> <br /> <br /> [[Category:Technical|Minutes]]<br /> [[Category:Minutes]]</div>

Goneall