https://wiki.spdx.org/index.php?action=history&feed=atom&title=Technical_Team%2FMinutes%2F2020-08-25 2026-05-07T15:37:10Z Revision history for this page on the wiki MediaWiki 1.23.13 https://wiki.spdx.org/index.php?title=Technical_Team/Minutes/2020-08-25&diff=4872&oldid=prev 2020-08-25T18:04:44Z

<p>Created page with &quot;August 25, 2020 == Attendees == * Kate Stewart * Thomas Steenbergen * Nisha Kumar * Gary O’Neall * Peter Shin * William Bartholomew * Jim Hutchison * Philippe Ombredanne T...&quot;</p> <p><b>New page</b></p><div>August 25, 2020<br /> == Attendees ==<br /> * Kate Stewart<br /> * Thomas Steenbergen <br /> * Nisha Kumar<br /> * Gary O’Neall<br /> * Peter Shin<br /> * William Bartholomew<br /> * Jim Hutchison<br /> * Philippe Ombredanne<br /> <br /> Topics:<br /> * Vulnerability Profiles<br /> * Identity<br /> * OpenChain Licensing group update – SPDX 3.0<br /> <br /> ==Call with OpenChain Automotive Workgroup==<br /> * Thomas attended a meeting with the OpenChain Automotive Workgroup<br /> * Led my Endo-san<br /> * Proposal to create an automotive profile<br /> * Created a PR: PR #468 https://github.com/spdx/spdx-spec/pull/468<br /> * Several updates are in progress for the PR<br /> * Several enhancements to 3.0 requested<br /> ** Need a product entity<br /> ** Need a condition entity<br /> ** Need defects<br /> *** Defects go against conditions<br /> ** Which product is involved<br /> ** Where in the lifecycle (e.g. prototype)<br /> * Questions on scope<br /> ** Initial proposal would use SPDX for specifications communications back to supplier<br /> ** Should that be in scope for SPDX?<br /> * Discussion on defects<br /> ** Should we expand vulnerabilities to include functional defects, others?<br /> ** Thomas suggested vulnerabilities are very similar to other types of defects<br /> ** Relationship to patches<br /> * Desire to communicate document expiration or other way to include the concept of time<br /> ** Should we have a time profile?<br /> ** Stating a future expectation like “I will release a new version on xxx” may violate the principle of stating facts<br /> ** would like to avoid modeling contractual relationship<br /> * Audience – who is the intended recipient?<br /> ** Example OEM supplier may document information which is not intended to be communicated to end users<br /> ** Steve suggested that the process used for communicating documents may provide the mechanism for what is communicated to whom<br /> <br /> ==Identity==<br /> * Came out of the 3T SBOM comparison to SPDX<br /> * Current SPDX identity is a structured string (e.g. PERSON: (email))<br /> * Proposal to structure this as a separate class in SPDX 3.0 using person, organization and tool as subclasses<br /> ** name and email would be properties<br /> ** There may have been an identity type in the linking profile<br /> *** Nisha will check with Santiago<br /> * Nisha asked if there was a process to propose promoting a field from a profile to the base profile<br /> ** Those proposals can be raised in the SPDX tech meeting<br /> ** Wait until we see commonalities between profiles before promoting<br /> ** This could be used for identity properties used in linking profile and perhaps vulnerabilities<br /> * No concerns about adding structure to the identity<br /> <br /> ==Vulnerability Profiles==<br /> * 3T SBOM put vulnerabilities in the defects<br /> * Thomas presented the 3T defects spec<br /> ** Similar structure to SPDX<br /> ** Additional relationships<br /> * Proposal to use defects rather than vulnerabilities<br /> * Question on having defect types or subclasses<br /> * Could use different profiles for security defects vs. other types of defects<br /> * DefectRepsonse<br /> ** Not necessarily a fact like a defect is a fact<br /> ** Should have a relationship to defect<br /> ** Examples – isAffectedBy – this would be a relationship and more fact based<br /> * Should state SPDX 3.0 design principles<br /> ** Could start with the spec statements about scope for SPDX 2.2<br /> * Should Vulnerabilities be their own element or a “type” of defect?<br /> * Source – specify the source<br /> ** Rating is likely related to the source<br /> ** Suggestion to move the rating to the source<br /> ** Score may change over time<br /> ** Vulnerability creation time may be different than document creating time<br /> ** From Peter: CVSS has an equation under the hood - Weight_for_base * base + weight_for_impact * impact + ….<br /> * Dependency Tree Profile proposal<br /> <br /> ==Next Week==<br /> * SPDX 3.0 design principles (e.g. facts based, scope related)<br /> * Dependency Tree Profile proposal – or template<br /> <br /> [[Category:Technical|Minutes]]</div>

Goneall