VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG)

[SecurityCRob]

VEX is an emerging spec, and tool set to ease the burden of determining vulnerability exploitation likelihood within components used during a build. OpenVEX is a community currently developing a spec, GO and Rust libraries, and a toolset to further determine minimal requirements as defined by the CISA VEX working group, GO and RUST libraries enabling the ingestion of metadata in other VEX implementations, and the toolset to create, merge, and attest VEX documents. OpenVEX has asked for adoption within the OpenSSF vulnerability disclosures working group towards its spec, libraries, and toolset being further developed and towards ISO specification through the PAS Submitter process

We are seeking the working group's opinion on whether or not to adopt the OpenVEX project (https://github.com/openvex/spec) as an official OpenSSF project under the Vulnerability Disclosure Working Group. If adopted, the working group would collaborate with the project team on refinements and updates to the specification, collaborate on possible tooling to implement the project seamlessly into developer workflows, and provide support for the ultimate proposal of OpenVEXas an industry standard through the OpenSSF's industry standardization processes.

Working Group Maintainers, Collaborators, and Contributors (https://github.com/ossf/wg-vulnerability-disclosures#governance) are invited to formally vote on their choice to adopt this project, or not. Additionally, non-working group members are welcome to express their opinions, but not as official voting members of the group. Members please complete your vote and/or add your comments no later than the next working group meeting, 22March2023, so the results can be discussed in our call.

If this project is adopted by the WG, next steps would be following the TAC's project submission procedure for donated content & intellectual property review (https://github.com/ossf/tac/blob/main/process/project-lifecycle.md).

[AevaOnline]

@Tomalrich @henkbirkholz @roywill @JLLeitschuh &others -- I think the discussion you are having ("what is OpenVEX and what is its relationship to VEX, VDR, etc?") is an important discussion, and it's important that the WG and TAC have a shared understanding of the project maintainers' vision for the project.

I suggest taking that discussion offline (either to slack or email or to the next WG meeting) for high-bandwidth resolution and then updating the OpenVEX project documentation to clarify that distinction in a manner that is understandable by folks who have not been deeply involved in the VEX working group for the past two+ years.

I believe that will help move us towards an easier voting decision.

[AevaOnline]

@dlorenc @lehors in looking a little closer at the contribution stats for the two code projects (vexctl and go-vex), it appears the majority of contributions to both came from one developer. According to GitHub, one of the maintainers' only contribution to those projects has been to add himself to the CONTRIBUTORS.md file, and two of the maintainers have never contributed code to either project. Following up on others' procedural comments, I would like to better understand how this project meets the multiplicity of maintainers required for admission into the OpenSSF. Are there other artefacts demonstrating the community engagement which ought to be reviewed?

This is incorrect, Google and VMware are "officially supporting" OpenVEX and the have "contributed" to this PR - openvex/community#6

@costica11 - the PR you linked is merely a change to the MAINTAINERS.md file, not a substantive contribution to the project. Is there somewhere else we should be looking?

[oej]

@dlorenc "Hey lets go create a standard", is not how standards get developed in any of the standards bodies I've work in since 1992, including the IETF, Supply Chain Integrity, Transparency and Trust (SCITT) work group, which I'm currently working on.

I do not agree. IETF is open to work on a document if there's enough energy in a group wanting to take on the work. In some cases this has resulted in overlapping IETF RFCs which is just fine.

[henkbirkholz]

I suggest taking that discussion offline (either to slack or email or to the next WG meeting) for high-bandwidth resolution and then updating the OpenVEX project documentation to clarify that distinction in a manner that is understandable by folks who have not been deeply involved in the VEX working group for the past two+ years.

@AevaOnline, thanks. If this discussion goes somewhere else, could someone please leave a pointer here? I am really bad at following bread crumbs - unless they are really bright and shiny :sparkle:

[kaniini]

Just addressing one last piece of misinformation:

The purpose of OpenVEX is to identify vulnerability scan results that are false positives.

This is one application of OpenVEX. It is not the only application. The purpose of OpenVEX is to leverage presently existing microstandards such as PUrl to enable sharing of data relating to vulnerabilities in a framework that looks and feels like something aligned with the various draft documents produced by the VEX working group.

In reality, its functionality is a superset of the functionality discussed by the VEX working group, so it can "turn off" scan results (by saying a component is fixed, or not affected, or whatever), but it can also say "we fixed this component by doing XYZ" etc.

And being a microstandard itself (indeed, OpenVEX is only a JSON-LD vocabulary), it can also be trivially extended by other microstandards to provide even more functionality.

Ultimately the purpose of OpenVEX isn't so much "turning off scan results" as it is enabling FOSS maintainers and security teams to collaborate on vulnerability management. The vision is one of an ecosystem backed by rich vulnerability data presented as linked data, with OpenVEX attestations being a description of how a vulnerability is mutated (e.g. confirmed, fixed, acknowledged or whatever else we want to say about the vulnerability). If you can imagine, for a second, an SBOM which references an OSV advisory, which then references some OpenVEX attestations, we want to enable tooling which can present all of that information in a concise and tactically useful way.

[henkbirkholz]

OpenVEX is only a JSON-LD vocabulary

You are basically saying OpenVEX is an ontology T-Box. If that is case, OpenVex would be more aligned with SPDX than I initially realized. Maybe W3C would be a good candidate venue to move from individual specification to standards text? To be honest, I am a little bit surprised, as I cannot see any linked data in https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md. Is that a planned next step? (and sorry for not keeping it offline. At the moment, the shiny bread crumbs lead here).

[kaniini]

At the moment, we have indeed not shown any examples of how the linked data aspects will work. That work is forthcoming. But it has always been the goal since OpenVEX was conceptualized last year.

And yes, it is our intention that OpenVEX fits very well into SPDX, especially the upcoming SPDX 3. That isn't a preference or value judgement for SPDX however, they are just both RDF ontologies so it makes sense that they would mesh well together. We also tried to make sure that users of CycloneDX SBOMs could make use of OpenVEX in the same way.

[rjb4standards]

@dlorenc "Hey lets go create a standard", is not how standards get developed in any of the standards bodies I've work in since 1992, including the IETF, Supply Chain Integrity, Transparency and Trust (SCITT) work group, which I'm currently working on.

I do not agree. IETF is open to work on a document if there's enough energy in a group wanting to take on the work. In some cases this has resulted in overlapping IETF RFCs which is just fine.

@oej , IETF has an entire process before a work group can be setup to work on a standard, this requires BOF's and a formal chartering process, before a work group is approved. It's definitely not a "rag tag" "ad hoc" thing, it's a well defined process that must be followed. That's my experience, yours may be different. I've worked in other ANSI SDO's and they all have similar requirements before standards development begins.

[SecurityCRob]

Before I vote one way or the other. I need to ask. Does an acceptance vote to move this under the governance of the OpenSSF at a technical level and the release of IP rights? I don't profess to be an expert in where the state of the art is here, but I do know that most of the linux distros are based on some previous with cherry-picked solutions to some CVE. This declaration can be represented in the SBOM and thus ties into the language of VEX\VDR or the final replacement. Having that clarified and worked through is important. I do know that SBOM's support two serialization formats, but this does come at a complexity cost of walking the graph. If we could strive to not repeat this in this space great. I am not sure that OpenVEX though will trump any move from CISA or influence from other governments going forward. If the desire is to push far enough into the vanguard space with tooling and thus own mindshare, I should point out that we have remnants of that approach over broad areas from S\MIME to ... Undoing or supporting the quirks should be a non-goal.

@roywill I believe, procedurally, if this project is adopted, next steps are to go through LF legal review and the IP transfer. Can anyone from the TAC confirm this or provide perspective on these steps?

yes, LF Legal review and IP transfer would be next steps if this is adopted by the WG.

[costica11]

@AevaOnline Apologies, I didn't mean to confuse you. I thought you might be already aware of all the mess related to this. From what I know, these people were contacted to be listed for namesake, for publicity and for a potential future OpenSSF submission. I am not sure if Google and VMware officially reviewed this project and gave their clearance. There was already a "closed" discussion with the L.F staff about all this. There was a coordinated PR with the OpenVEX announcement. I think that the project is abusing the power of media manipulation and access to the L.F. staff as well as the positions in OpenSSF.

[SecurityCRob]

Fam - can we please keep this discussion professional, respectful, and focused on the merits/detriments of adopting the OpenVEX body of work and efforts? It is very exciting that we've generated so much external interest, and I hope many of you that are joining us for the first time for this dialog stick around and continue to contribute to our ongoing efforts within the open source vulnerability disclosure community, but the purpose of this issue is for our working group members to ask questions and ultimately express their desires around any future collaborations with the OpenVEX group. It is easy to see the passion everyone is bringing here, and we'd like to find productive ways to harness that for the betterment of our ecosystem, maintainers, and downstream consumers.

[henkbirkholz]

it is our intention that OpenVEX fits very well into SPDX, especially the upcoming SPDX 3

With respect to future collaborations, joining the SPDX Defects Profile Meeting might be a good path towards that goal.

I am bad at finding invites... As far as I can tell, the meeting occurs weekly: Wed, 14:00 CST (currently 20:00 CET), at https://meet.jit.si/SPDXDefectsMeeting

[dlorenc]

@AevaOnline Apologies, I didn't mean to confuse you. I thought you might be already aware of all the mess related to this. From what I know, these people were contacted to be listed for namesake, for publicity and for a potential future OpenSSF submission. I am not sure if Google and VMware officially reviewed this project and gave their clearance. There was already a "closed" discussion with the L.F staff about all this. There was a coordinated PR with the OpenVEX announcement. I think that the project is abusing the power of media manipulation and access to the L.F. staff as well as the positions in OpenSSF.

All I'm going to say here is that this is completely false.

[ByteHackr]

+1 as an Independent OpenSSF Contributor.

[rjb4standards]

Fam - can we please keep this discussion professional, respectful, and focused on the merits/detriments of adopting the OpenVEX body of work and efforts? It is very exciting that we've generated so much external interest, and I hope many of you that are joining us for the first time for this dialog stick around and continue to contribute to our ongoing efforts within the open source vulnerability disclosure community, but the purpose of this issue is for our working group members to ask questions and ultimately express their desires around any future collaborations with the OpenVEX group. It is easy to see the passion everyone is bringing here, and we'd like to find productive ways to harness that for the betterment of our ecosystem, maintainers, and downstream consumers.

@SecurityCRob My apologies if anyone has taken offense to anything I've posted here. My intent was to inform, which is also the intent of this posting. It's important to understand that many people have been working on vulnerability disclosure reporting for many, many years and the community of interested parties has worked toward a common vision for communicating software vulnerability status to consumers. REA has offered to withdraw it's open-source VDR format, if the community can agree to adopt the CycloneDX VDR/VEX format. REA also endorses the CSAF Security Advisory (profile 4) as a means to communicate with consumers when a new vulnerability is reported, identifying products which are affected, The people working on OpenVEX can continue to pursue, yet another method to communicate vulnerabilities, but recognize you are not alone, and you will be attempting to compete with the good work that has already been done in this area, primarily through NIST with their Vulnerability Disclosure Reports, ref: standard SP 800-161 RA-5 and US government mandates to follow NIST Guidance in OMB M-22-18. My message to you is: This is not a "green field" space you are entering and your proposal represents a competing option to what already exists and is being implemented in standards, i.e. CycloneDX following NIST SP800-161. I respectfully ask that you consider joining the CycloneDX VDR initiative to focus our collective energies on a common, existing solution, following NIST guidance, instead of creating a competing initiative. Again, I apologize to anyone that was offended by my statements. I hope you will give this serious consideration and work with the OWASP Community on a common solution.

[SecurityCRob]

it is our intention that OpenVEX fits very well into SPDX, especially the upcoming SPDX 3

With respect to future collaborations, joining the SPDX Defects Profile Meeting might be a good path towards that goal.

I am bad at finding invites... As far as I can tell, the meeting occurs weekly: Wed, 14:00 CST (currently 20:00 CET), at https://meet.jit.si/SPDXDefectsMeeting

I'd LOVE to see folks from both SPDX and CycloneDX continue to engage with this group going forward. Perhaps we could get some reps to come in and do a quick demonstration for our members and showcase how the tools both can help maintainers and consumers manage with risk around open source vulnerabilities and show how devs can leverage the great software and communities around both.

[kurtseifried]

EDIT: meant to quote:

I suggest taking that discussion offline (either to slack or email or to the next WG meeting) for high-bandwidth resolution and then updating the OpenVEX project documentation to clarify that distinction in a manner that is understandable by folks who have not been deeply involved in the VEX working group for the past two+ years.

Can this discussion be documented and shared here? The GSD is keeping an eye on this issue as it affects us (the good news is we can probably support it, I think, but the bad news is I'm not exactly sure what "it" is), in other words I'm not entirely clear on what the intended purpose of OpenVEX is, e.g., what problem does it solve (technical? procedural? you want to make sure there's a reference open source implementation?) and have any other options have been considered (and found to be lacking?). Thanks.

I can say from experience that inventing a new data format has long-term effects, witness CVE v5 just finally becoming sane, the first four versions were not bad, but they weren't great, I didn't get any community feedback/project feedback so I went ahead with what I thought was best (and often times the only way to truly learn and explore a problem space is to build a solution, theory craft only gets you so far).

My only concrete ask is: please make a schema version (e.g. "schema_version": "1.0") a mandatory tag, and please consider making an identification tag (e.g. "data_type": "openvex") mandatory as well. This is hugely helpful when ingesting lots of data from lots of different sources, that may or may not label/mix and match their data.

[zmanion]

If anyone really wants to continue the more off-topic aspects of this issue, I opened discussion https://github.com/ossf/wg-vulnerability-disclosures/discussions/127.

[zmanion]

+1 as an OpenSSF VDWG member.

[dlorenc]

The recording from last week's presentation is now available on Youtube: https://www.youtube.com/watch?v=MBn1Ph6aBxc

[costica11]

@dlorenc Thanks for the response. Are you saying that the complete statement is false or just a part of it? Could you please let us know what is the major "open" contribution constantly made by Google and VMware in developing OpenVEX prior to this PR https://github.com/openvex/community/pull/6 ?

[oej]

@dlorenc "Hey lets go create a standard", is not how standards get developed in any of the standards bodies I've work in since 1992, including the IETF, Supply Chain Integrity, Transparency and Trust (SCITT) work group, which I'm currently working on.

I do not agree. IETF is open to work on a document if there's enough energy in a group wanting to take on the work. In some cases this has resulted in overlapping IETF RFCs which is just fine.

@oej , IETF has an entire process before a work group can be setup to work on a standard, this requires BOF's and a formal chartering process, before a work group is approved. It's definitely not a "rag tag" "ad hoc" thing, it's a well defined process that must be followed. That's my experience, yours may be different. I've worked in other ANSI SDO's and they all have similar requirements before standards development begins.

Absolutely. But that doesn't prevent competing proposals to get working groups. You have many standards for voice over the net, for presence and chat too.

[JasonKeirstead]

@dlorenc The only two slides in that deck of substance - 13 and 14 - both have multuple statements each that are flat-out wrong. I agree we need to stick with the vote - that slide deck shouldn't factor into it as-is.

Jason - I've given you comment access to the document. I'd like to fix anything incorrect, please feel free to leave a comment there if anything seems wrong.

I was out on PTO last week, so am just getting to this now. I have added all of my comments on that deck. I won't repeat them here but encourage others to go read them. The TL;DR for me is that the claims in those two slides are not data-driven - they are subjective, and seem written with a very specific point of view in mind (commercial - the "we" statements are not referring to the WG or OSSF). If they are data-driven, then the data should be provided...

[Foxboron]

I have added all of my comments on that deck. I won't repeat them here but encourage others to go read them.

Just a heads-up that you can't see the comments added to the slides without having edit rights on the deck. Anyone casually following along to this issue can't see them.

[dlorenc]

Just a heads-up that you can't see the comments added to the slides without having edit rights on the deck. Anyone casually following along to this issue can't see them.

I've now opened up comment access. If it starts getting abused I'll have to drop it to a list specific to this WG or something. I don't see a way to allow viewing comments without adding them :(

[Foxboron]

I've now opened up comment access. If it starts getting abused I'll have to drop it to a list specific to this WG or something. I don't see a way to allow viewing comments without adding them :(

Thanks!

[henkbirkholz]

Just a heads-up that you can't see the comments added to the slides without having edit rights on the deck. Anyone casually following along to this issue can't see them.

I've now opened up comment access. If it starts getting abused I'll have to drop it to a list specific to this WG or something. I don't see a way to allow viewing comments without adding them :(

Understood. Thank you for the benefit of doubt. Maybe comment on inappropriate comments for a while before considering doing permission churn again. I think the gesture is duly appreciated. One question: what does "this WG" refer to?

[AevaOnline]

One question: what does "this WG" refer to?

@henkbirkholz this discussion is occurring within a GitHub Issue within the Vulnerability Disclosure Working Group (WG). The URL for this Issue lists the WG name. This Issue opened a request for that WG to vote.

For more information on the OpenSSF's organizational structure and what Working Groups are in this context, please refer to the OSSF/TAC repository.

[dlorenc]

Understood. Thank you for the benefit of doubt. Maybe comment on inappropriate comments for a while before considering doing permission churn again. I think the gesture is duly appreciated. One question: what does "this WG" refer to?

Sorry folks, that didn't last long. I'm dropping permissions again to view only. Just click "request access" if you want to comment.

[ctcpip]

Projects must be aligned with the OpenSSF mission and either be a novel approach for existing areas or address an unfulfilled need.

Respectfully, OpenVEX doesn't pass this sniff test for OpenSSF project adoption.

[nathan-menhorn]

+1 OpenVEX seems really useful for filtering CVEs.

[tpepper]

I'm disappointed to have my team's motivations and by proxy the reputation of folks like rnjudge brought into this discussion. At VMware our emphasis is in doing what we can to contribute to the open source evolution of both standards and interoperable tools/process implementations in the software supply chain security space. Our initial involvement with this early OpenVEX project is directly aligned with both that and the track record visible with our involvement in areas like purl, OCI, SPDX, and even bringing CycloneDX support to tools we're interested in. Our involvement is because we believe the future needs actively bridged to be one in which the ecosystem is performing trustworthy exchange of artifacts and metadata, composed and consumed by diverse tools via common, machine readable formats (yes plural). It's unlikely that one solution will fit all sizes in this complex technical domain. Whether this proposal moves forward now, later, or not at all, please expect VMware to be contributing in these spaces and hopefully then with more time our presence comes to surprise people less.

[rjb4standards]

@tpepper I've worked with Rose Judge on SPDX and her honesty and integrity is impeccable.

[henkbirkholz]

One question: what does "this WG" refer to?

@henkbirkholz this discussion is occurring within a GitHub Issue within the Vulnerability Disclosure Working Group (WG). The URL for this Issue lists the WG name. This Issue opened a request for that WG to vote.

For more information on the OpenSSF's organizational structure and what Working Groups are in this context, please refer to the OSSF/TAC repository.

@AevaOnline Thanks. I am finding my bearings now.

[underkay]

+1 for OpenVEX adoption. VEX is an important development in the world of vulnerability management and this WG being a part of the growth and improvements through OpenVEX is a targeted and valuable way to contribute.

[jonmuk]

+1 Work to do here but this is a great start / approach

[SecurityCRob]

+1 I vote to adopt the OpenVEX project as a SIG underneath the Vuln Disclosure WG, help continue to develop the lightweight spec and associated tooling, coordinate with the larger VEX group, work with assorted other efforts like CSAF and tooling such as SPDX and CycloneDX, and work to make issuing all types of advisories more seamless and frictionless for oss developers.

[lehors]

I've hesitated to vote because like others I very much dislike the tone this discussion has taken but as it has been pointed out this proposal appear to fail the requirements set up by our process. On that basis I vote no.

If anything this should have helped Chainguard identify other interested parties and once they have beefed up a bit the community around this they should be in a better position to bring it here.

I would advise making an effort to better explain why this is needed. The main argument against using Vex seems to be that Vex is immature and lack adoption. I find that pretty unconvincing. I would prefer an approach that starts from Vex and that extends/modifies it if found necessary. It also seems that one common motivation is to have tools. But why not build tools for Vex?

[SecurityCRob]

No worries. Abstaining is perfectly legitimate (as is voting "for" or "against" a particular issue). Our goal is to let folks express their thoughts and opinions and ultimately give the members an opportunity to help shape our path forward. Healthy debate and dialog help us create stronger and more diverse ideas to support our communities and goals. I appreciate your participation!

[Tomalrich]

I would advise making an effort to better explain why this is needed. The main argument against using Vex seems to be that Vex is immature and lack adoption. I find that pretty unconvincing. I would prefer an approach that starts from Vex and that extends/modifies it if found necessary. It also seems that one common motivation is to have tools. But why not build tools for Vex?

Arnaud, there are tools for all the VEX formats, but all three formats lack widespread adoption. There's no question there is a big problem with identifying exploitable vs. non-exploitable component vulnerabilities in a software product. However, it appears now that VEX as described in the three published NTIA/CISA documents doesn't address that problem well.

Steve Springett, whose CDX community created the most successful VEX format, recently stated in this blog posthttps://owasp.org/blog/2023/02/07/vdr-vex-comparison that VDR is a much more useful format for this purpose than VEX. That assertion can and should be debated. I honestly think this group could spend its time much better discussing how software users can best be advised of exploitable and non-exploitable component vulnerabilities in the products they rely on. This might be a document or an API; it might be called VEX, VDR or something else. But this discussion needs to happen.

Tom Alrich LLC

312-515-8996

---

From: Arnaud J Le Hors @.> Sent: Thursday, March 16, 2023 10:02 AM To: ossf/wg-vulnerability-disclosures @.> Cc: Tom Alrich @.>; Mention @.> Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125)

I've hesitated to vote because like others I very much dislike the tone this discussion has taken but as it has been pointed out this proposal appear to fail the requirements set up by our process. On that basis I vote no.

If anything this should have helped Chainguard identify other interested parties and once they have beefed up a bit the community around this they should be in a better position to bring it here.

I would advise making an effort to better explain why this is needed. The main argument against using Vex seems to be that Vex is immature and lack adoption. I find that pretty unconvincing. I would prefer an approach that starts from Vex and that extends/modifies it if found necessary. It also seems that one common motivation is to have tools. But why not build tools for Vex?

— Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1472152488, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY66HNMOE5QMU4GCXPX3W4MTRXANCNFSM6AAAAAAVUEWJZU. You are receiving this because you were mentioned.Message ID: @.***>

[rjb4standards]

An example CycloneDX VDR is available here: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/CDXVEX/CDX14.xml I refer to this as an "implied" VDR model, where only SBOM components with reported CVE are listed. An explicit VDR model lists all SBOM components in a software product and their vulnerability status, including those with no reported vulnerabilities. https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json

[JasonKeirstead]

Steve's blog is one of the most important links in this entire thread.

I have a different takeaway from it though, and it is actually what Steve himself says in the last sentence "Could it be that a hybrid approach of supporting both VDR and VEX is the way forward? In the end, hopefully, pragmatism will be the clear winner."

The sooner everyone agrees that the concepts of VDR and VEX are largely trying to do the same thing and the only reason they have different names is due to historical happenstance, and we should union the venn diagram and get it over with, the better this all will become.

[rjb4standards]

Full Disclosure: Over a year ago, REA offered to contribute the open-source VDR XML Schema to the Linux Foundation, no strings attached. The offer was not accepted. REA is prepared to withdraw our own open-source VDR format, if the community agrees to support the CycloneDX VDR format.

There are three distinctive concepts at play, which are completely different in their purpose: CSAF Security Advisory = Purpose: Identify all products that ARE AFFECTED by a vulnerability CSAF VEX = Purpose: Identify all products that ARE NOT AFFECTED by a vulnerability NIST VDR = Purpose: For ONE specific Product/SBOM, list all vulnerabilities at the SBOM component level; living document

aDolus offers a more detailed description of the differences between VEX and VDR

NOTE: The aDolus article incorrectly states that a VDR is static. A VDR is a living document that is updated as needed and is always available at a known URL, as shown in the SPDX V2.3 spec

[costica11]

@tpepper Sorry my question to @dlorenc was not meant to challenge VMWare's open source contributions. I am aware of the great work that VMware and @rnjudge has contributed with to the other projects you have mentioned (purl, OCI, SPDX, etc. ) . However,  I could not find any major open contribution to the "Open"Vex projects. Also, @AevaOnline's questions were not answered. My intention is to just understand what exactly is VMWare and Google's major open contributions to the "Open"Vex project and how they have achieved maintainer status.

Some people who joined this voting process were taking part in the in-depth review of Notary V2 ( https://github.com/cncf/toc/issues/981 ). Many inconsistencies can be found, in what the OpenVEX project says and what the reality actually is, by just doing a basic search on the openvex Github org ( https://github.com/openvex ).

If OpenVEX was like any other normal open source projects that organically joined OpenSSF, this wouldn't be an issue. But the OpenVEX project and Chainguard team have their own agenda and interest and they are taking advantage of their privilege as an OpenSSF TAC, GB member.  

• The Chainguard has a preference for formats and they have spread misinformation about other formats and specs to promote OpenVEX.
• The Chainguard team have contacted the L.F staff and they have pre-planned a potential submission to OpenSSF in the early days of the project. They have used their OpenSSF TAC role privilege for OpenVEX' project submission.
• The Chainguard team used other organization names as maintainers to meet the OpenSSF requirements and media publicity.
• I was informed that the format interoperability effort is impacted as the Chainguard team continues to spread misinformation through the media.

The adoption of "Open"VEX with OpenSSF will only result in keeping OpenSSF further away from other formats and in creating more conflicts. The OpenSSF shouldn't encourage projects like these that use OpenSSF as a platform for promoting their agenda.

I kindly request the TAC chair (@bobcallaway) and vice chair (@AevaOnline) to review these allegations, evidence related to my statements can be provided if needed.

[tracymiranda]

OK it's my turn to express disappointment to have my team's motivations and by proxy the reputation of folks like puerco brought into this discussion. At Chainguard we are committed to making open source software secure by default and driving technologies to solve problems as we come across them.

While a great deal has been made of maintainership in this issue I will call out that there is as yet not enough clarity from the TAC around process and requirements around accepting projects as top level ones vs under the auspices of the working group. And I will highlight that there are current OpenSSF projects under working groups with only maintainers from single organizations e.g. S2C2F. Nevertheless OpenVEX aims to build a strong community and bootstrapped with maintainers from multiple orgs.

To clarify some aspects of open source and the OpenSSF:

• We see open source as win/win, a rising tide that raises all boats. Starting a new project does not automatically create conflict or division - this is a zero-sum game mindset that we try to avoid. There are many great examples (e.g. in CNCF of seemingly competing projects thriving)
• Anyone is able to plan or propose a new project to the OpenSSF at any stage of the project to a working group.
• The GB or OpenSSF itself have nothing to do with projects being accepted to the OpenSSF. The TAC members have no special privilege for project submission.
• Simply because you disagree with what someone says does not automatically make it misinformation. And if items need clarification or correction ourselves and media publications are happy to listen, please reach out.
• Chainguard have been active participants in the SPDX & CycloneDX interoperability effort which we see as extremely important, we are not the party leaving the table.

We will continue to drive for interoperability where possible, and new elegant solutions where it makes sense - all in service of making open source secure by default.

[tpepper]

My intention is to just understand what exactly is VMWare and Google's major open contributions to the "Open"Vex project and how they have achieved maintainer status.

Primarily I want to comment on voting process and selection criteria relative to OpenSSF: At this point it's quite unclear what criteria voters are applying here. Multiple comments in the thread have these ambiguous notions of "major" or "enough" in ways not backed clearly by the project lifecycle. OpenSSF needs better metrics of sufficiency for sandboxing and subsequent graduation.

Second though, trying to put on the hat of a reviewer looking at git repos and this new org on GitHub, and knowing of the quality and passion of folks like @cpanato, @puerco, and @rnjudge: It looks like common co-travelers openly and collaboratively doing early initial review/comment, and that participation then elevating to a bootstrap role. That's not exactly uncommon in open source, and I'd argue is even laudable. Bootstrap may be followed by formal elections. Or not? Governance of tiny early projects is different from large established ones. The project though should have documented process for it, OpenSSF should expect that, and even maybe offer templates.

I can't speak to @costica11 's other comments as I have literally zero knowledge of anything related to activity which may predate that open collaboration on the openvex git repos. (I do suspect the same types of clarifying process and documentation improvements in OpenSSF might have helped with the Notary situation they reference.)

Again it feels strangely unfortunate that we're in a position where taking an initial open source collaborative interest in something published on GitHub is suddenly a negative for individuals and a project.

[SecurityCRob]

OK folks, I want to thank everyone for their patience and perseverance through this last week. At this stage, we are going to pause comments on this issue and speak at the next TAC call about this matter. At this point, I count voting 10 members expressing agreement to adopt the project and 5 members turning it down. After our TAC meeting I will be reaching out to the outstanding eligible members to see if they are willing and interested in participating.

[SecurityCRob]

A majority of members have expressed their opinion and voted for this issue.
Summarizing: 11 working group members have expressed their approval to adopt this project as a sandbox software project and a SIG underneath our working group. 5 members voted to not adopt. Additionally, 14 non-members express support to adopt this and 4 non-members opposed the idea.

We will move forward to legal review/ip-transfer and request the TAC formally votes to confirm the group's desired path forward. Thank you to everyone that participated in this conversation, and we look forward to everyone continuing to collaborate as we move forward.