Skip to content

General Meeting/Minutes/2021-12-02

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 2021-12-07 by Podence.

  • 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
  • New release of SPDX Java Tools available at https://github.com/spdx/tools-java/releases/tag/v1.0.3
  • 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

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

Categories: General, Minutes