OpenSSF Group Redesign & Alignment Proposal

[SecurityCRob]

In the June2025 OpenSSF Governing Board meeting & follow-on TAC Face-to-Face meetings and working sessions, Staff was asked to propose some options to realign and reorganize the technical work of the foundation to ensure to support our “4 Pillars”strategy and MVVSR roadmap. Among the goals: streamline the groups and the meetings on the calendar where possible.

The TAC reviewed the initial proposal and two options on Oct. 13, 2025 (original proposal available at the bottom of this document). Based on the discussions and feedback from that meeting, we have prepared a revised proposal for the TAC’s review and approval, available here: https://docs.google.com/document/d/1rllnUCbNT7OhKYWtFWNw9Yvm71WI-20QK4rStpqjBm8/edit?tab=t.0

[mlieberman85]

Overall, I'm in favor with this initial reorganization, however I still think we can go further here. I think this is good for next year, but I would like us to revisit if we can later next year.

[joshbressers]

What happened to moving SBOM Everywhere to being a WG?

[mlieberman85]

My takeaways from the GB and TAC meetings discussing this was SBOM as a WG would have significant overlap with the Supply Chain Integrity Working Group. In general the working groups have fairly broad scope.

[joshbressers]

The supply chain working group has never shown an interest in the SBOM everywhere group, I would like to understand the overlap

SBOM Everywhere meeting has a consistent attendance of 10-15 per meeting (higher than almost all the other working groups). The coffee chat generally has 20-30 attendees. We publish a few papers a year. This is without any real support from the OpenSSF

In fact the last thing we did as a group was a comment on the CISA RFP for the minimum elements which we were told we cannot claim was a comment from the OpenSSF, which was rubbish and none of us will ever work on such a thing for the OpenSSF again

I have no doubt if we had some proper support and attention we could accomplish quite a bit more. My understanding was we were working to make this a proper WG. I have spent a decent amount of time writing the new charter.

Finding out about this from a GitHub issue is a sad situation

[mlieberman85]

I feel like maybe there's been some miscommunication or misunderstanding here. The SCI working group would love to include SBOM related work, and we've discussed it in the past. Happy to hop on a call and chat this over.

In fact the last thing we did as a group was a comment on the CISA RFP for the minimum elements which we were told we cannot claim was a comment from the OpenSSF, which was rubbish and none of us will ever work on such a thing for the OpenSSF again

I'd like to know more details about this. This is the first time I'm hearing about this.

[steiza]

There's a lot here! Let me start by re-emphasizing what @SecurityCRob said - these are proposals from staff, as requested by the governing board, not mandates.

Staff and current leads of working groups (WGs) have started meeting with technical initiatives (TIs, e.g. SIGs and Projects) to talk about moving. The WG and the TI need to agree in order for a move to take place.

What happened to moving SBOM Everywhere to being a WG?

You probably know this, but just to make sure we're on the same page, to do so you'd go through the process listed on https://github.com/ossf/tac/blob/main/process/working-group-lifecycle.md.

The supply chain working group has never shown an interest in the SBOM everywhere group, I would like to understand the overlap

Again, just to make sure we're on the same page, in the past month the Supply Chain Integrity WG got 3 new interim co-chairs as the WG reconsiders what content is covered in their meetings and what's in scope. If you haven't already, it could be a good time to check out the recent meeting notes and consider reaching out!

SBOMs of course are a large topic, and (again, as you know!) folks are using them for a wide variety of use-cases including doing vulnerability management, internal license compliance, to meet external compliance needs or contractual obligations, etc. To me, those are definitely software supply chain security topics, although inside of GitHub we often talk about "ingredients + integrity" - so I could see a future in which we either:

• Have a Supply Chain Security mega-WG that spans integrity (the current remit) + ingredients (e.g. SBOMs and related topics).
• Start a Supply Chain Ingredients WG?? We probably wouldn't literally do this as the names and abbreviation are quite similar to the existing WG.

But again, these are all proposals / ideas, not mandates.

[joshbressers]

I don't want to see this end up as some back and forth. So I'm going to explain what I see from my perspective

Some time ago Kate Stewart and I spoke with @SecurityCRob about making the SBOM Everywhere SIG a proper working group, and then in the future we could discuss homing the various SBOM tools beneath this. It was agreed this was a good idea

I created a new Charter to reflect this plan
https://github.com/joshbressers/sbom-everywhere/blob/SBOM-WG/CHARTER.md

The next thing I heard about working groups was in the issue that has this discussion. I don't pay as close of attention as I could, but I also don't think I should have to scour every TAC meeting note

Now, that's surprising sure, but the thing that was upsetting is the SBOM groups are footnotes in the above documents. They're not listed properly in the table

I don't think the OpenSSF staff gives SBOM Everywhere nearly the support it needs or deserves, but that's fine, whatever, we deal with it. But at this moment it feels like one of those situations where "maybe if we ignore them long enough they'll leave"

[SecurityCRob]

I've spoken with Kate here in Tokyo this week and provided the link that @steiza shared in his comment above plus links to the foundation Mission, Vision, Values, and Roadmap (mvvsr) plus the priorities from our new board chair. As stated, we have been asked to give a proposal, and we're now in the phase of gathering feedback so the TAC can make choices about how we can more efficiently organize ourselves. We've been operating with the same core working groups almost since the inception of the OSSF 5 years ago and have seen many members, projects, and initiatives come and go since then. Several of our original WG leads have transitioned to new roles and no longer participate in our community any longer, which prompted the brainstorming on how best could we focus our resources and make ties between the technical initiatives.

SBOM and VEX are very near and dear to me personally, in addition to the value these specs and tools add to the ecosystem. If we have sufficient projects and artifacts the groups want to collaborate on they can be performed either in the existing sig or as a full working group, but "upgrading" to a full WG introduces some additional effort requirements for the group leaders that don't exist at the sig-level. The proposal shared works on the assumption that the current tooling WG where the sbom sig lives today being dissolved with the active projects to a number of WGs (predominantly to the Supply Chain Integrity group) since at this time it is most thematically aligned to a bulk of the current initiates that need a new collaborative home (a few might move to the vuln WG as well).

Staff is glad to work with anyone interested in going through the WG proposal process to prepare things for the TAC to review and vote on.

Ad I told Kate this week, SBOMs are crucial elements for our communities, our members, and government entities (cough, cough CRA), and I'd love to see us commit to more work and leadership building upon the longtime work of the SIG, the new Coffee club, and spiritually moving the CISA group collaboration forward.

Above and beyond SBOMs, patches are welcome for other ideas on how best we can make connections across our 30ish technical initiatives. Please keep the suggestions and comments coming so the TAC can make the best informed decision possible.