THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx

General Meeting/Minutes/2021-12-02

From SPDX Wiki
Jump to: navigation, search
  • Attendance: 33
  • Lead by Phil Odence
  • Minutes from last approved
  • Phil will company membership announcement before end of week
  • We will be move General Meeting minutes to GitHub and crowdsource during meetings.

Microsoft and SPDX - Adrian/Steve

  • Microsoft standardizing on SPDX [Adrian Giglio]
    • Why SPDX?
      • On ISO standard path
      • Already participating
      • Great group
    • Why build their own tool?
      • Already had tooling
      • Easy to move to SPDX
      • Needed certainty to meet NTiA standards
      • Utilize MS Detection
      • Needed a great range of environments
      • Support for very large, complex build systems; layered builds
    • The Tool
      • Built on .Net and available for Windows/Linux/Mac
      • Available as build step in Azure
      • Plan is to open source
      • Pulls OSS data from a variety of build system formats
    • Future
      • Proving by early March, then rolling out across Microsoft
      • Exploring different methods of SBOM distribution including web portal
      • Exploring signing with others in the industry
  • MCR Distributing SPDX SBoMs for Microsoft content [Steve Lasker]
    • How to distribute secured supply chain components? Specifically SBOMs
    • Supply chain artifact challenges:
      • artifacts get promoted across environments, including production assets getting pulled from the Internet into restricted networks
      • private virtual networks within cloud infrastructure
    • Solution: Validation artifacts need to travel together with the supply chain objects
      • by default, SBOM might get blocked from being accessed due to "airgapped" / VNet setup
      • instead, create a private registry within each vnet; with shared internal registry hosting all artifacts + SBOMs, then promoted into each vnet
    • ORAS: need signatures to be separable, verifiable, able to be validated, prior to bringing artifact / binary into the environment
      • Microsoft built this for Azure Container Registry, but customers share with other registries and other infrastructure; registries should be a broader standard => OCI Artifacts, ORAS Artifacts
      • Signatures and SPDX SBOMs get attached to the graph
      • ACR support for ORAS Artifacts today => customers can store SPDX SBOMs today: https://aka.ms/acr/supply-chain-artifacts
    • Opportunity: having SPDX document travel alongside the target artifact; CLI that can natively push / pull / validate SPDX SBOMs to Registries
    • What does the SPDX community want to see in an SBOM?
      • recording EULA text?
      • something validated at the time the content is used? => needs to be accessible along with the artifact itself
  • Questions/Comments
    • Dick: what about having vulnerability disclosures together as a part of the distributed info?
      • Appreciate that the SPDX structure enables describing all the pieces of what went into a software build in the first place => static information at a point in time
      • Scan results are things that you learn about over time => e.g. might learn later about a problem that was discovered after it was shipped
      • Scan results will continue to be additive, whereas the SBOM itself doesn't change
      • Dick: some vendors are running scans and producing NVD reports together with vendor's findings; making that info available together with the SBOM. During customer risk assessments, they can see beforehand if a CVE is reported => if shows up in the disclosure, that helps address the risk.
      • Scan results, etc., could be attached to the other documents that are included in the registry
      • Eventually, looking to have a web-browsable portal to easily access these documents. But, the automation is the interesting part.
    • Just this morning, this was announced to be becoming part of an OCI working group; previously getting proven within the ORAS project
    • Sebastian: Ostree (Fedora): https://fedoraproject.org/wiki/Changes/OstreeNativeContainer
    • Signature format: shipped in Notary v2, but working on expanding via conversations with the broader community. Needs to be able to be validated broadly.
    • Dick: NIST workshop that took place this week: ability to distribute SDLC evidence and policy data. Will that be part of this?
      • Viewing this as plumbing / core infrastructure, in a generic way; new types will emerge for what types of artifacts are used to be deployed / promoted on this infrastructure
      • Because it's generic / abstracted, any new type can be hosted on this infrastructure

 

Tech Team Report – Kate/Gary/Others

  • Tools
  • Specification
    • Focused on the Core modeling
    • Made progress on collections, packages, and document definitions and relationships
    • Significant testing of the model with different use cases and serialization considerations


Legal Team Report - Jilayne/Pau/Steve

 

Outreach Team Report -

  • No update, but Sebastian sent an email to the General Meeting list with notes on behalf of the team.


Attendees

  • Phil Odence, Black Duck/Synopsys
  • Adrian Digli, Microsoft
  • Steve Lasker, Microsoft
  • Sebastian Crane
  • Steve Winslow, Boston Technology Law
  • Dick Brooks, REA
  • Rich Steenwyk, GE Healthcare
  • Annie
  • Brad Goldring, GTC
  • Jeff Schutt, Cisco
  • David Edelsohn, IBM
  • Jilayne Lovejoy, Red Hat
  • Aveek Basu, NextMark Printers
  • Marc Gisi, Windriver
  • Gary O’Neall, SourceAuditor
  • Philippe Ombrédanne- nexB
  • Dick Brooks
  • Alex Rybek
  • Brend Smits, Philips
  • Christopher Lusk, Lenovo
  • Christopher Phillips
  • Fellow Jitser
  • Jilayne Lovejoy, Red Hat
  • Mashid
  • Kendra Morton
  • Marco
  • Majira
  • Michael Herzog- nexB
  • Mike Nemmers
  • Molly Menoni
  • Paul Madick, Jenzabar
  • Rose Judge, VMWare
  • Vicky Brasseur, Wipro
Retrieved from "https://wiki.spdx.org/index.php?title=General_Meeting/Minutes/2021-12-02&oldid=4931"