2020-08-25¶

Archived page

Read-only copy of the SPDX wiki. The wiki is no longer active; its content has moved to https://github.com/spdx. Last edited 2020-08-25 by Goneall.

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

Categories: Technical