VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) #125
Comments
|
The US Federal government requires federal agencies to follow NIST standards and guidelines, i.e. SP 800-218 and SP 800-161 RA-5, which defines NIST Vulnerability Disclosure Reports (VDR). There is no government requirement to provide a VEX document to indicate that a software product is not affected by a vulnerability. NIST VDR attestation is explained here I also recommend reviewing the OWASP side-by-side comparison of VEX and VDR |
|
I've participated in the NTIA/now CISA VEX working group meetings since the second meeting in September 2020. You need to understand two facts about OpenVEX: |
|
I'm not a voting member of the WG and my support is probably obvious, but non-binding +1 from me! |
|
As I have previously stated in discussions around standards, I don't think this Working Group should get involved in standardization efforts beyond pointing out where existing standardization efforts occur. It's a no from me. |
|
I'm not a voting member of the WG either, but I'm a fan of VEX and like that OpenVEX avoids taking sides in the SBOM format debate. +1 from me. |
|
A working group can decide if it will take on specification or formal standardization efforts, and on what (as long as it meets the usual OpenSSF requirements on scope, openness, licensing, etc.). In particular, formal standardization is a lot of work and shouldn't be taken on lightly. However, I do want to clarify that formal standardization is a possible path for OpenSSF work. The OpenSSF Charter expressly denotes the recommended license for work that might lead to formal standardization. The Linux Foundation's Joint Development Foundation (JDF) is recognized as an ISO/IEC JTC 1 Publicly Available Specification (PAS) Submitter. I don't think this proposal is recommending that it become a formal standard, just that the WG take this work on as a specification effort. If the desire is to make it a formal standard, that should be raised at some point (probably as a separate issue). |
Correct. We've taken the necessary precautions to set ourselves up for that work using the community specification process, but there's a long road before we're ready to start it. |
|
I'm a little perplexed why this proposal wasn't brought to OASIS, which is already working on VEX. Why setup a "competing VEX initiative"? OASIS is an international standards organization, I worked with OASIS on the ebXML standard, now listed as ISO 15000 standard. Sorry, but this "fracturing" of VEX efforts makes no sense to me. |
|
I am not sure how we are tracking votes. I as well vote no. Much like @Foxboron I disagree that this group should be throwing weight behind a competing standard to things that already exist, further complicating adoption of VEX in general by making more confusion. We should be rallying behind things that exist and making them better. |
@trevrosen Sorry, this is an incorrect statement. OpenVex/Chainguard staff do prefer SPDX and they have spread misinformation about CycloneDX in multiple meetings. They also had "closed" discussions with the SPDX team before making public announcements. |
|
No. Unless CISA (or other standards authority) adopts this variant of VEX, I am against endorsing OpenVEX. I also view it as having a fracturing effect at OASIS and SBOM standards groups are working towards unification. It is disingenuous to create/endorse something that competes with (and may overwrite) known work being done at associate organizations we recognize (like CISA and OASIS) without any attempt to encourage collaboration. |
|
REA has been processing SPDX and CycloneDX SBOM's for 3 years in SAG-PM and they are both viable, effective SBOM formats - no need to create drama where none needs to exist. |
|
@costica11 I'm merely pointing out that SBOM format agnosticism is a stated design goal in the spec's FAQ. 😄 |
|
+1 on this proposal. |
|
+1 👍 |
|
VEX is key to automating the vulnerability remediation lifecycle, and OpenVEX is a step forward in that direction, +1. |
i don't know if i am able to vote but +1. So, superficially i am tracking openvex. Is it fair to say enablement with tooling to enable threat intel and management could help adoption and that an investment could be made to get this going? @shebashio is happy to find paths to enable. My bottom line is this is 100% an integral component or artifacts that make use of what often is not understood. vulnerability data is mostly leveraged to identify code level hard exploits. Threat intel is a different beast. |
|
Based on some comments, I'm guessing some people may not be aware that VEX reports on software products that ARE NOT AFFECTED by a new vulnerability. A Security Advisory (SA) identifies products that ARE AFFECTED by a new vulnerability. This is the yin-yang view of the same CVE VEX=not affected SA=affected. |
|
+1! I'd love to see more tooling and OSS innovation around VEX through OpenVEX! |
|
I'm not a part of the TSC or the WG, but I vote +1 for open standards and tooling for VEX, which I strongly believe we will need as a "negative SBOM" or even a "software disclaimer of materials" in order to be able to qualify SBOMs. I would have preferred a solution contained within SBOMs themselves, but this addition appears to be the best we can do for now. |
|
@trishankkarthik FYI there already are VEX Standards that can be embedded in in the SBOM, like CycloneDX VEX. This request is to invent another one. |
|
Well, this is interesting... OWASP, who is an OpenSSF associate member, has a VDR/VEX format. SPDX which is a another LF project is developing their own - to be compatible with OWASP CycloneDX. Having a third format with ties to OpenSSF would likely be a public relations issue for the foundation as it promotes continued fragmentation rather than unification. Also, keep in mind that VEX is only half of the solution. The other half is VDR which is already a requirement in some federal and commercial instances. |
|
For those chiming in - I'd kindly request that you take the time to review the presentation I shared today in the WG meeting: https://docs.google.com/presentation/d/1ekre4ML3tMZ8pODAdLKIwsi1BsiT_q3o_QifTKkW5L0/edit#slide=id.p It addresses a lot of these questions. This is a clearly a heated topic, so I'd also kindly request that we keep this issue on-topic and scoped to the vote @SecurityCRob initiated it with. |
|
@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. |
|
@dlorenc There are a number of OpenSSF members in capital markets (GS, JPMC, Citi, MS, etc), and a number of those organizations block access to google docs (Slack too, btw) due to a variety of regulatory and other reasons. That's unlikely to change anytime soon. Would be great if important presentations like this were available through another channel such as download via GitHub. The continued insistence within LF communities to use google docs (and Slack) precludes organizations in highly regulated industries that can't use google docs from fully participating. CC @brianbehlendorf @mindthegab |
|
I think Rob means don't allow access or do block access. I agree with Rob but a path that doesn't substantially increase the cost of collaboration requires work to define beyond the scope of this WG and should be raised at the TAC.
Brian
On March 9, 2023 4:34:33 AM GMT+01:00, Robert Underwood ***@***.***> wrote:
@dlorenc There are a number of OpenSSF members in capital markets (GS, JPMC, Citi, etc), and a number of those organizations don't block access to google docs (Slack too, btw) due a variety of regulatory and other reasons. That's unlikely to change anytime soon. Would be great if important presentations like this were available through another channels such as download via GitHub. The continued insistence within LF communities to use google docs precludes organizations in highly regulated industries that can't use google docs from fully participation. CC @brianbehlendorf @mindthegab
--
Reply to this email directly or view it on GitHub:
#125 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
Yup. Edited my comment above. Apologies for the typo. Thank you @brianbehlendorf. If y'all truly want banks at the table, along with their membership fees, this reality needs to be accounted for. In light of events such as the WhatApp fines to banks (google that if you're not familiar) this state of affairs is unlikely to change any time soon. Please don't assume all OpenSSF members can access Google docs. If you want to hold a vote, and want input from the community, level the playing field so everyone has the same access to all information. This issue has been raised many times, over many years, by the financial services participants in the LF. This is not new. Just PDF stuff and put it in a GitHub repo if you have to. |
|
Thanks Rob. I'll follow up on this in another forum, to return this topic to OpenVEX as a project within the OpenSSF. |
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.
Thanks for calling this out! I've converted it into a PDF and attached it here. |
|
@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 openvex/community#6 ? |
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. |
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... |
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 :( |
Thanks! |
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? |
@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. |
Sorry folks, that didn't last long. I'm dropping permissions again to view only. Just click "request access" if you want to comment. |
Respectfully, OpenVEX doesn't pass this sniff test for OpenSSF project adoption. |
|
+1 OpenVEX seems really useful for filtering CVEs. |
|
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. |
|
@tpepper I've worked with Rose Judge on SPDX and her honesty and integrity is impeccable. |
@AevaOnline Thanks. I am finding my bearings now. |
|
+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. |
|
+1 |
|
+1 |
|
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. |
|
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! |
|
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 post<https://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 GitHub<#125 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVCDY66HNMOE5QMU4GCXPX3W4MTRXANCNFSM6AAAAAAVUEWJZU>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
An example CycloneDX VDR is available here: |
|
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. |
|
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: 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 |
|
@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 ( cncf/toc#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 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. |
|
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 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. |
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. 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. |
|
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. |
|
A majority of members have expressed their opinion and voted for this issue. 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. |
and others
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).
The text was updated successfully, but these errors were encountered: