Technical Team/Minutes/2020-08-25

From SPDX Wiki
Jump to: navigation, search

August 25, 2020


  • Kate Stewart
  • Thomas Steenbergen
  • Nisha Kumar
  • Gary O’Neall
  • Peter Shin
  • William Bartholomew
  • Jim Hutchison
  • Philippe Ombredanne


  • Vulnerability Profiles
  • Identity
  • OpenChain Licensing group update – SPDX 3.0

Call with OpenChain Automotive Workgroup

  • Thomas attended a meeting with the OpenChain Automotive Workgroup
  • Led my Endo-san
  • Proposal to create an automotive profile
  • Created a PR: PR #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

Vulnerability Profiles

  • 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

Next Week

  • SPDX 3.0 design principles (e.g. facts based, scope related)
  • Dependency Tree Profile proposal – or template