Proposal: Funding Critical Projects POC with commercial vendors

[edelsohn]

Identifying and assisting critical links in the open-source software supply chain remains a challenge for the open-source community and the Open Source Security Foundation. I am writing to introduce a proposal for the OpenSSF to orchestrate existing assets and organizations as an experiment to improve the security posture of key, under-resourced components of the open-source community. The proposal outlines a multi-faceted approach to enhance the security and stability of these projects by leveraging existing funding sources, engaging innovative business models, and applying advanced analytical techniques.

Key aspects of the proposal include:

1. Objectively identifying critical open-source projects based on their importance and the potential impact of security incidents.
2. Engaging with these projects through existing channels in a collaborative manner to provide additional resources effectively.
3. Creating an efficient pathway from funding organizations and identification to open-source projects.

I believe this approach offers an innovative and end-to-end solution to the challenges faced by the open-source software supply chain and will significantly contribute to narrowing security gaps recognized by the community, industry, and governments. The open source supply chain ecosystem is huge with many different communities and cultures, which necessitates multiple solutions. I believe that a solution piecing together existing, commercial solutions is one approach that is worthy of an experiment, such as preliminary funding for a proof of concept.

The attached proposal suggests the companies TideLift and Cyberfame, and funding source AlphaOmega, which have specific expertise in their respective components. The proposal can be generalized to include additional, specific vendors, can be converted to an Request for Proposal from multiple vendors, or can be converted to a competition, as the OpenSSF TAC prefers if and when it chooses to adopt the proposal or a variant.

I encourage the OpenSSF to pursue solutions to the software supply chain challenge with a more nimble, adaptive and light-weight approach. I look forward to discussing the attached proposal further and exploring how the OpenSSF can deploy creative solutions to improve the security posture of critical Open Source projects.

Funding Critical Open Source Projects.docx

[SecurityCRob]

Thanks for filing this issue David. We'll get this on the schedule to discuss at our next TAC call (23July2024).

[sevansdell]

Thanks for bringing this to the TAC call today. I recommend an alignment/brainstorming meeting with A/O, SCI WG leads, and staff that commented on today's call. I believe that will help crisp up the desired outcomes, and potential paths that avoid the appearance of "picking winners".

[edelsohn]

What does the "A/O" acronym mean?
Who would organize the brainstorming session?

[sevansdell]

What does the "A/O" acronym mean? Who would organize the brainstorming session?

A/O stands for Alpha Omega (comments from Michael Scovetta today). I believe as the idea generator, you would lead the brain storming session. In the spirit of open source, you might consider starting a slack direct message with participants you'd like and see if there is interest and collectively select a time? Here is a link to the TAC meeting minutes https://docs.google.com/document/d/1-zrtagRnPd75TDT1zRxrtxE9SpMIBJdPmaolaw4woQA/edit#heading=h.95gahrlfxbmu so you can refresh on the participants. I'd include SCI WG leads too.

[lehors]

I think @scovetta could help make the connection.

[lehors]

One thing I'm wondering is whether the proposal should really include # 1 - the identification of critical projects. How many such list do we really need? Couldn't we just leverage the list from Alpha Omega or Security Critical Project for instance and go straight to # 2?

[edelsohn]

The proposal intentionally is utilizing another form of analysis to obtain another viewpoint on criticality.

[codonell]

Just an outside observer, but I agree with @edelsohn, it seems like a very good experiment to run if we can also get the data to be made public.

I'm very curious about the dependency analysis, because I've not seen "binutils" show up on any of the critical lists, though "glibc" does show up... but the static linker, really any static linker for ELF binaries is a critical part of the infrastructure for building such binaries (wether you're using ld.bfd, lld, or mold) that are then loaded by a dynamic loader.

In some cases the dependencies are implicit, others explicit, and at the lowest level I'd figure that those with a commercial incentive would know... but that runs into vendor neutrality questions. Which isn't a new problem, I think some kind of objective RFQ with guard rails could solve that?

[SecurityCRob]

from a logistics/process perspective, this proposal will need adjusted to document a few things. Please refer to https://github.com/ossf/tac/blob/main/process/TI%20Funding%20Request%20Process.md for the full process.
The proposal needs to be aligned with a specific TI and have someone that is willing to act as the lead to help drive this effort.
The request will need adjusted to ask for something more specific, typically "We are requesting X amount of funding to achieve Y result in Z timeline." Once the TI has agreed to sponsor the effort, a completed funding request that includes all the required data elements should be filed within the TAC GH.

[sevansdell]

I agree with @crob above, and would like to defer this until the requested adjustments are made.

[SecurityCRob]

A quorum of the TAC met on 17Sept to discuss Q3 TI Funding Requests.

The consensus of the group was that this request needed more information and as this is written puts the vendor-neutrality of the group in question by hand-picking members/vendors. We very much want to avoid conflicts of interests. There also appears to be little community/TI engagement on this. If this effort were ever to move forward, we would want to see broad discussion and collaboration from one of our Technical Initiatives. We suggest taking the idea to the Securing Critical Projects working group or perhaps Alpha-Omega, as this is very much in line with what they have worked on in the past.

The TAC will not fund this request at this time.