Also attached are slides from Adrian and Steve’s very interesting presentations.

https://wiki.spdx.org/view/General_Meeting/Minutes/2021-12-02

< General Meeting‎ | Minutes

·         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.

Contents

 [hide] 

• 1 Microsoft and SPDX - Adrian/Steve
• 2 Tech Team Report – Kate/Gary/Others
• 3 Legal Team Report - Jilayne/Pau/Steve
• 4 Outreach Team Report -
• 5 Attendees

·         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

·         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

·         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

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

·         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