SPDX December General Meeting Minutes
Also attached are slides from Adrian and Steve’s very interesting presentations.
< 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.
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
· 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
· 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
· New release of SPDX Java Tools available at https://github.com/spdx/tools-java/releases/tag/v1.0.3
· 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.
· 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
· 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
· Kendra Morton
· Michael Herzog- nexB
· Mike Nemmers
· Molly Menoni
· Paul Madick, Jenzabar
· Rose Judge, VMWare
· Vicky Brasseur, Wipro