Hi everyone!

As every year, Google runs their Summer of Code program, where contributors get the opportunity to become part of Open Source communities. The SPDX Project has participated in the program in a number of years in the past. The way it works is that we publish project ideas and, if selected, newcomers to open source express their interest in them. The ones finally selected will spend their summer writing code under the guidance of mentors from our project. In order for contributors to join our community and help us, we have to publish a set of ideas where help is needed!

Therefore, this is a plea for ideas – and more importantly, mentors who can guide the new contributors and help them accomplish their projects!

Firstly, we are looking for project ideas! Either small or large, either incremental improvements to existing open source code or new pieces of software; everything is welcome!

Please read the basics on https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html and then write a couple of lines on your great idea.

I’ve (hastily) created a special repo for all this: https://github.com/spdx/GSoC

Feel free to create PRs with your ideas!

Perhaps even more important than ideas, we are also looking for mentors! Please get in contact via the repo if you are willing to help new members become active participants to SPDX this summer. Each project should have at least two mentors (a primary and a secondary one) who will guide the contributors in their journey.

Feel free to open an issue in the repo if you want to discuss in more detail any of the above.

Looking forward to lots of participation!

-- zvr

PS. I’ve already added a project idea: help on the spec generation from our model files.

Off the top of my head I can think of other ideas like:

• Outreach: help with the website
• Legal: help with license submission tools, help with bulk import from other license lists
• Tech: help with SPDXv3 implementation in Java, Go, etc.

But all these need mentors, otherwise they cannot be realistically proposed.

Researchers at Indiana University’s Luddy School of Informatics, Computing, and Engineering are looking for participants in the study of SBOM feature preferences. This is an online and asynchronous study about which features impinge trustworthiness.  We ask you for fewer than fifteen minutes of your time to perform the virtual card sorting exercise and answer a few questions.

The features we ask you to evaluate are drawn from the best practices in SPDX. In this study, you will be asked about your preferences of factors. Upon agreeing to participate in the study you will be asked to perform a card sorting activity and answer a series of survey questions. http://factors.usablesecurity.site/

Please feel more than welcome to share with others that may be interested in labeling and SBOM.

Thank you for your time and consideration.

Peter Caven
L. Jean Camp

Thanks, Max. I think that “bug” has been there for a while. I will endeavor to eliminate it going forward.

Thanks for pointing it out.

Phil

Hey Phil,

just checked the meeting time and there seems to be an inconsistency:

  8am PT / 10 am CT / 11am ET 

mapps to 

  16:00 UTC

I assume that 16:00 UTC, as it is the usual time, is right?

Best

Max

On Wed, 2023-01-04 at 20:56 +0000, Phil Odence via lists.spdx.org

wrote:

> Meeting Time: Thurs, Jan5, 8am PT / 10 am CT / 11am ET /

> 15:00 UTC. https://urldefense.com/v3/__http://www.timeanddate.com/worldclock/converter.html__;!!A4F2R9G_pg!bWd3rF8EjW7s9brSyWmr2O-RuoX8paEeB6ECvZk4Nipc9JxTlJC091gerznSmnodvEuOwe3jl3m5h1pXyyNuLNNbIgg4HM16$

-- 

TNG Technology Consulting GmbH, Beta-Str. 13a, 85774 Unterföhring

Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Thomas Endres

Aufsichtsratsvorsitzender: Christoph Stock

Sitz: Unterföhring * Amtsgericht München * HRB 135082

Happy New Year, all. I hope you have a meeting on your calendar for Thursday. In case there is an issue, the conference info is included below.

No special presentation this month.

Also please note that last meeting’s minutes are not yet “pulled” into GitHub, so I have included at the bottom.

Meeting Time: Thurs, Jan5, 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: At the bottom of this email

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

#SPDX General Meeting Minutes - Dec 1, 2022

Administrative

• Lead by Phil Odence
• Minutes from last meeting approved

Attendance: 16

Steering Committee Update - Phil

• Lots of discussion of participation
• Certainly could use help on
• Tech- drafting 3.0
• Legal- license review
• Outreach- website
• Stay tuned for SPDX for Security article

Special Presentations

• Contribution to SPDX 3.0 Specification - Alexios
• Preliminary feedback from DocFest - Gary

Tech Team Report - Gary, William, Kate

• SPDX 2.3
• Updated .pdf from Jack; review and logging needed
• Python tools updated to reflect 2.3 - looking for testers at https://github.com/spdx/tools-python
• SPDX 3.0
• Core Profile - William/Gary/Kate
• Worked through bulk of outstanding punchlist, now just focusing on identity/agent clarifications.
• Established workflow to collect profile contributions (see talk from Alexios above)
• Licensing Profile - Steve/Alexios
• Profile contributions to SPDX 3.0 unblocked.
• Security Profile - Thomas/Jeff
• In addition to linking to VEX documents, team is evaluating minimal VEX elements to embed in SPDX to convey security info in a simplified manner
• Documenting Security Use Cases in 3.0
• Planning 3 hour workshops on 12/15 & 12/21 to move preliminary security profile information into the model.
• Build Profile - Brandon/Nisha
• Draft relationship and build element completed (https://github.com/spdx/spdx-3-build-profile)
• Created examples to validate two use cases, one github actions and YOCTO (including nested build)
• Dependency on identity/agent 3.0 model discussion.
• Working on presentation about Build and Safety for OCS Japan event.
• Usage Profile - Ito/Ninjouji/Asaba/Kobota
• Basic set of fields established but some possible overlap with Build Profile, to be discussed next week.
• Planning for presentation at SPDX Minifest at OCS Japan
• AI & Dataset Profile - Gopi/Karen/Kate
• Working on examples using Dataset profile, to look for coverage.
• Have worked though 3 Datasets, so far no adjustments needed, looking to get more examples from OpenDataology group.
• Will start to work through AI application examples in December, and upstream dataset profile
• Standford Cybersecurity talk mention of our work at: https://youtu.be/ZGnQGfzhwjI
• Prep for SPDX Minifest at OCS Japan
• Functional Safety - Nicole/Kate
• Diagraming of all safety artifacts in progress
• Some possible new relationships under consideration to be added.

Legal Team Update - Jilayne/Steve/Paul

• 3.19 released yesterday
• focused on documentation, made good improvements (more to do)
• some process discussions still in the works
• reworked FAQs, now in the repo so easier to update, welcome suggestions / additions via PRs
• 3.20 - lots of submissions ready for review
• most coming from Fedora adopting SPDX IDs
• previously, SPDX had based several additions off of Fedora's "good" licenses
• many are things that aren't just in Fedora -- e.g. Warner from FreeBSD has been weighing in; many are old licenses
• Process of how to review licenses -- aiming to make more accessible to people
• may have a training session for the community
• watch the spdx-legal mailing list for updates

Outreach Team Update - Sebastian/Alexios/Jack

• Working on messaging around SPDX and security -- making clearer and simpler for others to reuse as well
• Started to collect presentations about SPDX, or about SBOMs generally that mention SPDX -- will look to publish somewhere collectively - https://github.com/spdx/outreach

Attendees

• Alex Rybak (Revenera)
• Alexios Zavras
• Bob Martin
• Bryan Cowan (Fortress)
• Gale McCommons (Comcast)
• Gary O'Neall
• Jilayne Lovejoy
• Karen Bennet
• Marc-Etienne Vargenau
• Mary Hardy (Microsoft)
• Maximilian Huber
• Michael Herzog
• Paul Madick
• Phil Odence (Black Duck Audits, Synopsys)
• Ritesh Sonawane
• Steve Winslow

‘‘SEC. 524B. ENSURING CYBERSECURITY OF DEVICES.

‘‘(3) provide to the Secretary a software bill of

20 materials, including commercial, open-source, and

21 off-the-shelf software components;

This text is referring  to medical devices.

https://www.appropriations.senate.gov/imo/media/doc/JRQ121922.PDF

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

Hello Everyone,

I’ve heard the SBOM provision that was in the NDAA is under consideration for the Omnibus Bill.

I sent written testimony to the Senate Appropriations Committee deliberating the Omnibus Bill and posted a nearly identical version of my written testimony online:

https://energycentral.com/c/pip/letter-congress-please-don%E2%80%99t-hamstring-your-cybersecurity-staff

Please show your support for SBOM by sending written testimony to Congress.

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

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

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