It’s all moot now. The bill passed the House and Senate today and is on it’s way to the President’s desk.

https://www.congress.gov/bill/117th-congress/house-bill/7776/text

All of the software supply chain provisions have been gutted in the final NDAA.

Thanks,

Dick Brooks

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and report! ™

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

Eliot,

I’m not familiar with the GSA work you mention. Can you provide a pointer to GSA documents indicating that SBOM’s are required.

I’ve seen where SBOM’s are required in the Department of State Evolve RFP.

Also, why would ITI and others be lobbying Congress to have SBOM removed from the NDAA, as the linked article indicates.

There must be a reason. I suspect it’s because Congress creates laws, and the NDAA law makes SBOM a legal requirement.

FYI:

Please get the word out to restore the SBOM provision in the NDAA.

“I don't see why any member of Congress would want to hamstring their own cybersecurity professionals from monitoring and mitigating software vulnerabilities that are detectable using an SBOM. Members of Congress please help your own cybersecurity professionals that work so hard to keep you and your districts safe from hacker attacks. Restore the SBOM provision in the NDAA.”

https://energycentral.com/c/pip/industry-objections-spur-changes-cybersecurity-provisions-defense-bill%C2%A0%C2%A0

Thanks,

Dick Brooks

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and report! ™

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

Sending this to the SPDX list per Gary’s suggestion at today’s SPDX tech team meeting. .

Last Week I attended a FERC-DOE supply chain technical conference and a suggestion was made to host a “SBOM Vendor Day” to show the energy industry what is available for processing (creating/consuming) SBOM’s.

At this point it’s “just an idea” and there is nothing concrete. I’ve been collecting email from parties with an interest in participating in a SBOM Vendor Day, IF this “Vendor Day” concept comes to fruition.

Please email me if interested in participating in a SBOM Vendor Day presentation for the Energy industry.

FYI: So far OWASP and Microsoft have expressed interest in participating, IF this SBOM Vendor Day comes to fruition.

Thanks,

Dick Brooks

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and report! ™

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

Hi Keith,

The “Unexpected Error” usually indicates an issue with the validation tool itself.  Can you post an issue at https://github.com/spdx/spdx-online-tools/issues and attach a file that reproduces the problem?  Alternatively, you can email me the information at gary@....

Thanks,
Gary

Having also been in that call I would also like this clarification. The idea behind having this information available is for the recipient to make her or his own judgement on how accurate they expect such to be.

If this has been solved in the SPDX community that would be great. 😊 Steve’s comments on different “stages” was not something I had considered, but it does potentially complicate things.

BR J

Hoping to meet some people at this supply chain technical conference in Washington on December 7.

Please come out and show your support for SBOM in software supply chains and meet many of the people working on supply chain initiatives in the electric industry.

https://www.ferc.gov/news-events/events/joint-ferc-doe-supply-chain-risk-management-technical-conference-12072022

Thanks,

Dick Brooks

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

Never trust software, always verify and report! ™

http://www.reliableenergyanalytics.com

Email: dick@...

Tel: +1 978-696-1788

Hi Steve,

I’m going to include the SPDX tech group on the email thread – sorry to many of you for the duplication.

Steve – If you’re a member of that email we can continue the thread there.

There is a Build Profile working group which is tackling very similar problems for the SPDX 3.0 spec led by Brandon and Nisha (cc’d) – you may want to connect with that group.

For SPDX 2.3, I have a couple of thoughts and suggestions.  I think the Creation Information created date will provide the information on when the SBOM was created.  We don’t have any fields at the SPDX Document level to store and retrieve the build phase information, but we have added 3 new fields at the package level which may be useful:

• Built Date
• Release Date
• Valid Until Date

For a typical SBOM, the SPDX document will have a Document Describes which points to the package the SBOM is describing.  Although it isn’t direct, you could use the Built Date and Release Date along with the Creation information to determine where in the lifecycle the SBOM was created.  Since these are optional fields, the Telco SIG would need to specify that they be included for the package in the Document Describes field.

Using the comment field for information not in the SPDX spec is an acceptable practice – especially if the information is intended to be human readable.  You can also use an Annotation on the SPDX document for the same purpose.  The advantage of the Annotation is you can have more than one with each Annotation having a specific purpose.  For example, you could have an Annotation “Build-Phase: pre-build” and an separate annotation for unrelated information.

Best regards,

Gary

Steve,

SBOM’s are created to serve a purpose, for example some SBOM’s are used for license management, some are used for dependency tracking and the one I’m most familiar with is an SBOM used by a software consumer in a software risk assessment.

In the risk assessment case it’s imperative that the SBOM describe the contents of a software package used for installation and execution in a consumers digital ecosystem. Data in this SBOM, i.e. component names and versions, is more compatible with vulnerability databases when searching for CVE’s filed against component software, i.e. Log4j is a good example.

I can’t speak to SBOM’s used for other purposes.

Hi all,

One of the suggestions in today’s call for the OpenChain Telco SIG, where we’re discussing proposals for an SBOM standard for the Telecommunications industry, was:

> SBOMs conforming to the Telco SBOM Specification need to contain the information when the SBOM was created in the “Created” SPDX field and at what phase of the software build it was created (“pre-build”, “build-time” or “post-build”) in the CreatorComment SPDX field.

(See https://github.com/OpenChain-Project/Telco-WG/pull/15)

I raised a concern about ambiguity here, in that your application may be built from libraries that are built at an earlier stage, so the SBOM information may be created after some components are built, but before others. A recipient of the SBOM might also interpret each of these three phrases differently from the creator of the SBOM. I recall hearing that there have been conversations about many different SBOMs according to phase (source SBOM, build SBOM, deploy SBOM, cloud SBOM, etc.), so I wondered whether there was advice that the Telco SIG could lean upon, rather than trying to formulate a solution when it’s already a solved problem.

Apologies if this isn’t the right group.

steve

Small correction: Thurs is Dec 1.

 This month we’ll have a couple special presentations. Gary will give a debrief on Wednesday’s docfest. Alexios will walk is through the GitHub 3.0 directories so everyone knows how to contribute.

We’d like to add a regular General Meeting topic on presentation folks are delivering featuring SPDX. If you know if any recent or upcoming please add them to the repo created for this purpose: https://github.com/spdx/outreach/blob/main/SPDX-presentations.md

GENERAL MEETING

Meeting Time: Thurs, Dec 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html

Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

Administrative Agenda

Attendance

Minutes Approval:  https://github.com/spdx/meetings/blob/main/general/2022-11-03.md

Presentations – Gary and Alexios

Steering Committee Update - Phil

Technical Team Report – Kate/Gary/Others

• Specification and Profiles
• Overview
• Core
• Legal
• Integrity
• Defects
• Usage and Other Emerging
• Tooling

Legal Team Report – Jilayne/Paul/Steve

Outreach/Website Team Report – Jack/Sebastian/Alexios

 This month we’ll have a couple special presentations. Gary will give a debrief on Wednesday’s docfest. Alexios will walk is through the GitHub 3.0 directories so everyone knows how to contribute.

We’d like to add a regular General Meeting topic on presentation folks are delivering featuring SPDX. If you know if any recent or upcoming please add them to the repo created for this purpose: https://github.com/spdx/outreach/blob/main/SPDX-presentations.md

GENERAL MEETING

Meeting Time: Thurs, Dec 2, 8am PT / 10 am CT / 11am ET / 15:00 UTC. http://www.timeanddate.com/worldclock/converter.html

Conf call dial-in:

Join the meeting:
https://meet.jit.si/SPDXGeneralMeeting

To join by phone instead, tap this: +1.512.647.1431,,1310118349#

Looking for a different dial-in number?
See meeting dial-in numbers: https://meet.jit.si/static/dialInInfo.html?room=SPDXGeneralMeeting


If also dialing-in through a room phone, join without connecting to audio: https://meet.jit.si/SPDXGeneralMeeting#config.startSilent=true

Etherpad for minutes:

https://spdx.swinslow.net/p/spdx-general-minutes

Administrative Agenda

Attendance

Minutes Approval:  https://github.com/spdx/meetings/blob/main/general/2022-11-03.md

Presentations – Gary and Alexios

Steering Committee Update - Phil

Technical Team Report – Kate/Gary/Others

• Specification and Profiles
• Overview
• Core
• Legal
• Integrity
• Defects
• Usage and Other Emerging
• Tooling

Legal Team Report – Jilayne/Paul/Steve

Outreach/Website Team Report – Jack/Sebastian/Alexios

[this is also available as https://gist.github.com/zvr/c852b4a560ac2c67885c473034cd4a93]

# FOSDEM 2023 - SBOM devroom info and CfP

## Overview

[FOSDEM] is one of the world's premier meetings of free software developers, with thousands of people attending each year.

FOSDEM 2023 will take place on the weekend of 4-5 February 2023 and it will be an in-person event in Brussels once again!

For the first time, a track ("devroom") about Software Bill of Materials (SBOM) has been accepted in the conference.

## Details

The devroom will take place for half a day (09:00-12:50), on Sunday morning, as an in-person event in a room to be announced at a later time.

The SBOM Devroom at FOSDEM 2023 is an informal, technical, in-person event oriented to authors, users, and enthusiasts of FLOSS programs that produce, consume, or transform SBOMs.

While other domains like construction, mechanical engineering, or even computer hardware have long used the concept of Bill of Materials (BOMs), software traditionally has not followed this best practice. There have been efforts running for over a decade to address this, and recent developments have pushed forward the use and wide adoption of Software BOMs. Since most of today’s software is made up of Open Source, it is important that this information can be accurately conveyed. It includes, but is not limited to, metadata such as name and version but also licensing or security information.

The goal of the devroom is for interested people to get in touch with each other, exchange ideas and opinions, have interesting and hopefully productive discussions, and finally what is most important: to have fun.

**We are looking for presenters!**

## Call for participation

We are interested in presentations on any topic related to Software Bill of Materials: content, definitions, standardization efforts, tools, etc.

An indicative, non-exclusive, list of topics:

- Tools that produce SBOMs or related information

- Tools that consume SBOMs to generate other information

- Case studies and lessons learned from real-life use or introduction of SBOMs

- Use of different types of SBOMs (e.g., Source, Build, Runtime, etc.)

- Linking and verification of SBOMs to other relevant artifacts

- Special areas of interest not covered by current SBOM formats, that need discussion to be included

Any effort that would lead on increasing collaboration between different approaches and tools are particularly encouraged.

### Key dates

- 28 November: Submission deadline

- 16 December: Announcement of selected talks

- 5 February: SBOM devroom in FOSDEM - You must be available in person to present your talk

### Submission process

Please use the [Pentabarf] system to submit a talk proposal for the devroom. On the "General" tab, please look for the "Track" option and choose "Software Bill of Materials devroom".

Note: if you have used FOSDEM Pentabarf before, please do _not_ create a new account/username but rather use your existing one.

### First-time speakers

FOSDEM devrooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the devroom administrators personally if you would like to ask any questions about it.

### Submission guidelines

The Pentabarf system will ask for many of the essential details. Remember to re-use your account from previous years if you have one.

We will be looking for relevance to the conference and devroom themes, but essentially any presentation about SBOMs would qualify. Please note that the audience is expected to be _developers_ of Free and Open Source Software and will most probably be _knowledgeable_ in at least some aspects of SBOMs. Therefore aim your presentation accordingly.

Feel free to indicate your preferred duration for your presentation between 5 and 30 minutes, but please note that the final decision on duration will be made by the devroom administrators based on the number of accepted proposals. As the overall duration of the devroom is fixed and rather short, no presentation will exceed 30 minutes (including Q&A), so that more speakers can participate. Keep in mind that, as the event will be in-person, we also need to account for switching between speakers. Shorter presentation are **strongly** encouraged!

Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used for the recordings.

## Volunteers needed

To make the devroom run successfully, we are always looking for volunteers. If you will be attending the devroom and would like to help, please reach out to the organizers!

## Spread the word and discuss

If you know of any mailing lists or other online venues where this info and CfP would be relevant, please feel free to forward this document.

## Contact

The organizers of the devroom can be reached by sending email to sbom-devroom-manager@.... Please do not hesitate to contact us if you have any inquiry or suggestion for the devroom.

For any private queries, you may also contact the organizers directly:

- Alexios Zavras fosdem@...

- Kate Stewart stewart@...

[FOSDEM]: https://fosdem.org

[Pentabarf]: https://penta.fosdem.org/submission/FOSDEM23/

-- zvr