Technical Team/Minutes/2020-08-25

August 25, 2020

Attendees

Topics:

Thomas attended a meeting with the OpenChain Automotive Workgroup
Led my Endo-san
Proposal to create an automotive profile
Created a PR: PR #468 https://github.com/spdx/spdx-spec/pull/468
Several updates are in progress for the PR
Several enhancements to 3.0 requested
- Need a product entity
- Need a condition entity
- Need defects
  - Defects go against conditions
- Which product is involved
- Where in the lifecycle (e.g. prototype)
Questions on scope
- Initial proposal would use SPDX for specifications communications back to supplier
- Should that be in scope for SPDX?
Discussion on defects
- Should we expand vulnerabilities to include functional defects, others?
- Thomas suggested vulnerabilities are very similar to other types of defects
- Relationship to patches
Desire to communicate document expiration or other way to include the concept of time
- Should we have a time profile?
- Stating a future expectation like “I will release a new version on xxx” may violate the principle of stating facts
- would like to avoid modeling contractual relationship
Audience – who is the intended recipient?
- Example OEM supplier may document information which is not intended to be communicated to end users
- Steve suggested that the process used for communicating documents may provide the mechanism for what is communicated to whom

Came out of the 3T SBOM comparison to SPDX
Current SPDX identity is a structured string (e.g. PERSON: (email))
Proposal to structure this as a separate class in SPDX 3.0 using person, organization and tool as subclasses
- name and email would be properties
- There may have been an identity type in the linking profile
  - Nisha will check with Santiago
Nisha asked if there was a process to propose promoting a field from a profile to the base profile
- Those proposals can be raised in the SPDX tech meeting
- Wait until we see commonalities between profiles before promoting
- This could be used for identity properties used in linking profile and perhaps vulnerabilities
No concerns about adding structure to the identity

3T SBOM put vulnerabilities in the defects
Thomas presented the 3T defects spec
- Similar structure to SPDX
- Additional relationships
Proposal to use defects rather than vulnerabilities
Question on having defect types or subclasses
Could use different profiles for security defects vs. other types of defects
DefectRepsonse
- Not necessarily a fact like a defect is a fact
- Should have a relationship to defect
- Examples – isAffectedBy – this would be a relationship and more fact based
Should state SPDX 3.0 design principles
- Could start with the spec statements about scope for SPDX 2.2
Should Vulnerabilities be their own element or a “type” of defect?
Source – specify the source
- Rating is likely related to the source
- Suggestion to move the rating to the source
- Score may change over time
- Vulnerability creation time may be different than document creating time
- From Peter: CVSS has an equation under the hood - Weight_for_base * base + weight_for_impact * impact + ….
Dependency Tree Profile proposal