General Meeting/Minutes/2021-12-02

• 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

Legal Team Report - Jilayne/Pau/Steve

• License List version 3.15 was released and published to https://spdx.org/licenses on Nov. 14
• Shortened month for meetings due to Thanksgiving holiday in US
• Warner Losh presented to the team about FreeBSD's use of SPDX short-form license identifiers: https://docs.google.com/presentation/d/1mRWj7DCiicK57BqD4XzUMSZs51TpUUIYIgI-UcB8XDw/edit#slide=id.p

 

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