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).

[rjb4standards]

@dlorenc no problem Dan. You really are a big fan of censorship. I only invest my time in projects that stand a chance of succeeding, so it's appropriate, and proper for me to depart this discussion.

[tracymiranda]

Folks a reminder to abide by the https://www.linuxfoundation.org/legal/antitrust-policy and refrain from trying to discuss business plans or strategy.

[camaleon2016]

After watching the video; I'm totally confused on where Microsoft stands on VEX/OpenVEX, especially where the OMB M-22-18 requirements refer to NIST Guidance as requirements for software supply chain risk management. NIST's SP 800-161 defines the data that should be communicated to consumers as an attestation showing that software suppliers have checked each SBOM component for vulnerabilities. That artifact is called a Vulnerability Disclosure Report

@rjb4standards I'd be happy to discuss Microsoft's position offline. But as an FYI, I helped write the issue to vote on OpenVEX's adoption. And to be clear, we are only voting on it's adoption within the OpenSSF and to be further developed and worked on within the VD WG. Any additional discussions should take place aside from this issue. Or, perhaps an additional issue can be raised at a later time to address your concerns.

[stevespringett]

@annabellegoth2boss The SPDX and CycloneDX camps occasionally collaborate, and in fact we had a meeting yesterday to discuss interop. But I can confirm that no collaboration has happened between OpenVEX and CycloneDX.

[SecurityCRob]

@camaleon2016 Is this Microsoft's official position on OpenVEX?

@rjb4standards - Please stop this behaviour. Each member is entitled to their opinions and should vote based off of whatever factors they desire to weigh (including corporate or community goals, missions, desires). None of these opinions are considered an "official position" unless that member states so. If you seek a corporate position, you should approach those individual organizations for such. I also would invite you, since you appear to have deep interest in these topics, to more frequently engage with our group as part of our meetings, mailing lists, and other outlets to participate and you can share your insights with our community.

[SecurityCRob]

Folks a reminder to abide by the https://www.linuxfoundation.org/legal/antitrust-policy and refrain from trying to discuss business plans or strategy.

Also our Code of Conduct and be respectful to each other: https://openssf.org/community/code-of-conduct/

[rjb4standards]

I respectfully request to be removed from this group.

[kaniini]

But I can confirm that no collaboration has happened between OpenVEX and CycloneDX.

To be clear, OpenVEX has not collaborated with any SBOM project, as the purpose was to build a light weight microstandard that is used for vulnerability disclosure. The use case is not specific to SBOMs, but has applications which are complementary.

[costica11]

"While there are pre-existing solutions, IMHO they have hit local optimums and have not achieved broadscale adoption, especially for open source projects. "

Again this is incorrect information. The CycloneDX VEX and VDR have been adopted by both open source and commercial reputed security tools and vendors.

OpenSource Projects: Anchore grype Apache Solr   CVE Bin tool Aqua Trivy AppThreat/dep-scan Lockheed Martin Hoppr Cop OWASP DependencyTrack Vexy etc.

Commercial vendors: Anchore,  AquaSecurity,  Contrast Security,  Checkmarx, debricked, IBM, NowSecure,  PaloAltoNetworks, QWIET AI Rezilion, Sonatype,  StackAware,  Veracode,  etc.

[SecurityCRob]

But I can confirm that no collaboration has happened between OpenVEX and CycloneDX.

To be clear, OpenVEX has not collaborated with any SBOM project, as the purpose was to build a light weight microstandard that is used for vulnerability disclosure. The use case is not specific to SBOMs, but has applications which are complementary.

Depending on how this conversation and debate continues, this could be work that the WG picks up - to work with SBOM projects, standards bodies, and other tools. That direction is all dependent upon the participation and interest of the members. We are seeking opinions here and to also see if there is enough interest to move forward with this collaboration with the OpenVEX project. Several good points and current gaps have been discussed so far that we would want to see how to address and partner with other industry efforts if we move forward.

[SecurityCRob]

I respectfully request to be removed from this group.

I am currently working with the OpenSSF staff to accommodate your request.

[rjb4standards]

Thank you for your quick response to my request.

[JLLeitschuh]

(Voting member) I like the idea of VEX, but I see the issues that @stevespringett raised in his blog post on the topic. Keeping a full list of negative assertions of all the vulnerabilities you aren't impacted by is untenable for the industry. I like the closing line of his article:

NIST guidance recommends that vendors issue VDRs as a regular practice, thus asserting what vulnerabilities a product is potentially affected by. NIST guidance also allows for the inclusion of VEX and similar notification strategies.

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.

I'd like to hear from Allan Friedman before casting my vote, (I've pinged him), but, after reviewing the comments above, and the links provided, I'm leaning towards supporting this.

I respect that CycloneDX has a specification for defining a VEX format. That can be seen here:

https://cyclonedx.org/docs/1.4/json/#vulnerabilities_items_analysis_state If you want an example: https://cyclonedx.org/use-cases/#vulnerability-exploitability

However, this implementation couples the VEX information to the CycloneDX SBOM format. I don't know if that's a good/bad thing. However, I think that being able to ship both VDR and VEX assertions independently from an SBOM seems to make sense. Especially because, while an SBOM for a given release of a product will, hopefully, never change (because dependencies are, ideally, fixed at release time), the VDR and VEX assertions can vary over time as new vulnerabilities are announced.

[JLLeitschuh]

I respectfully request to be removed from this group.

You can also 'unsubscribe' yourself from this issue on the right sidebar. And if you are following this repository, you can unwatch this repository in the top right corner. Hope this helps. 😃

[rjb4standards]

@JLLeitschuh thanks for the advice. I have unsubcribed. Much appreciate your assistance.

[annabellegoth2boss]

(Voting member)

I am a "no" at this stage based on the OpenSSF's project criteria for maintainer/contributor diversification. While OpenVEX has a list of maintainers with different affiliations, the commit pool and history doesn't show the kind of diversified contribution the OpenSSF's criteria was going for.

I think the questions about OpenSSF's role in standards, collaboration with other formats, etc., are all worthwhile discussions, but should be revisited when OpenVEX is a bit more mature and shows multi-party participation.

[puerco]

How has the OpenVEX project engaged with the Cyclone and SPDX projects to date?

I can chime in here @annabellegoth2boss . I need to disagree Steve. The VEX working group includes members of both existing VEX implementations: CDX and CSAF. We have been shaping VEX in the group for months and the last hard push included a new round of Friday meetings where we (including CycloneDX) were trying to come up with the required compromises to ensure the least painful interoperability (especially given how cdx diverged early). OpenVEX is simply capturing that consensus in a minimal format.

I have been in contact with the CSAF folks too, in the meetings, in emails, on issues. And we already have working code in OpenVEX to interop between the two (we will get to CycloneDX at some point but it is harder because it is further away from the minimal elements doc, mostly waiting for 1,5 to drop).

SPDX is at a different stage. There is an early proposal to get VEX into the SPDX profile and I've talked to the folks involved at the defects meeting and last at FOSDEM. This engagement has been mostly trying to ensure the SPDX proposal does not break VEX or diverge from the latest documented elements as defined by the group.

So there is engagement going on.

[JLLeitschuh]

However, I think that being able to ship both VDR and VEX assertions independently from an SBOM seems to make sense.

That being said, there's nothing preventing CycloneDX from supporting OpenVEX as a standard in the future:

With CycloneDX, it is possible to reference a component, service, or vulnerability inside a BOM from other systems or other BOMs. This deep-linking capability is referred to as BOM-Link and is a formally registered URN.

Learn more about how CycloneDX makes use of BOM-Link.

CycloneDX VEX BOMs can also be used with alternative SBOM formats such as SPDX, but without the tight integration or support of an IETF standard for linkage. Vendor support may vary.

-Independent BOM and VEX BOM

[rjb4standards]

@puerco SPDX V2.3 already contains support for VEX and VDR: SPDX V 2.3 Appendix K

[puerco]

Those are references to external documents, I'm referring to the actual vex data expressed in SPDX. It is a planned feature for the security profile.

[ghost]

I am also a "No" at this stage, and am setting up time with Dan to better understand his point of view on this. Thanks all.

[stevespringett]

@puerco

capturing that consensus in a minimal format.

You do realize that many of the original people involved with VEX have left the group because consensus was never going to be achieved.

INFORM @JLLeitschuh

However, this implementation couples the VEX information to the CycloneDX SBOM format. I don't know if that's a good/bad thing

Its actually a good thing. CDX VEX is completely decoupled from an SBOM, and in fact, does not require an SBOM at all. Many of the CISA examples for CDX do not have SBOMs, nor does the Apache Solr VEX that someone else posted in this thread. Having both VEX and SBOM capabilities in the same specification does not mean they have to be present in the same document. CycloneDX recommends against this practice. But having both capabilities in the same specification dramatically simplifies the toolchain and reduces overall cost associated with supporting both SBOM and VEX. I'll assume that SPDX (once they support it) will have similar benefits. CDX VEX can already be used with and without SBOM, including SPDX SBOM. From my understanding, SPDX will have the same capability when complete.

On the flip side, having VEX capabilities in an advisory format such as CSAF would also simplify the toolchain and reduce costs. Vendors such as RedHat and Oracle are doing that today.

[zmanion]

(Apologies, this is somewhat off of the voting topic)

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.

This dynamic of VEX == "not affected" / VDR == "affected" is inaccurate. One of the VEX status values is "affected."

I could imagine a VDR containing one or more VEX statements (presumably with status == affected).

VDR is very weakly defined by NIST. My read is that a typical security advisory, or a collection of advisories, meets the existing "specification" for a VDR. Seems reasonable to work on a more precise definition of VDR, but at least for now, that would be defined by the VDR implementation, and not NIST. Also, beyond general "follow NIST" guidance, it's not clear to me that anyone is actually required to produce a VDR. Even SP 800-161 RA-5 reads "should" and "may consider providing." Limiting VDR to only "affected" is a significant loss of signal.

[rjb4standards]

@zmanion IF VEX can contain affected products, will VEX eliminate the need for CSAF Security Advisories, which are used extensively to communicate when products are affected? Also, Allan Friedman' presentation, in this youtube video state clearly that VEX is a "negative security advisory" (around 12:50).

[ran-dall]

+1 (Voting member) I support this initiative

[stevespringett]

@zmanion I've had the unpleasant experience to have to (mandatory) supply VDRs to the feds going back over a decade. They did not call them VDRs, but that's what whey were. They are used and in some cases, are required.

IMO, I've always felt that VEX should have been nothing more than a vector and rating system, similar to CVSS, OWASP Risk Rating, etc, where the vectors could be used in any format that wanted to support it. It would have greatly simplified things.

[lehors]

I think @annabellegoth2boss is taking the right approach to this. It's definitely worth trying to be systematic and leave aside emotions and purely subjective opinions. We do have a process so it's good to lean on it.

@dlorenc you referred earlier to "many of the contributors to OpenVEX" but browsing through all the openvex repos I only see about 10 contributors. Are there more? Thanks.

PS: and in case, it's not clear: I'm just trying to get the facts straight!

[dlorenc]

@dlorenc you referred earlier to "many of the contributors to OpenVEX" but browsing through all the openvex repos I only see about 10 contributors. Are there more?

That number sounds about right for contributors. More are always welcome! It's a rather minimal specification though, so I don't expect hundreds more. As more language libraries come on board things could vary, but we're seeing that happen outside of the organization too, which is great: https://github.com/seedwing-io/openvex-rs

[lehors]

I understand. Thanks.

[pdxjohnny]

Ping @anthonyharrison @terriko

[henkbirkholz]

VEX is basically a... "VBOM", right? It tracks the life-span of a vulnerability, the document is updated and maintained as more details, mitigations, and remediation are added, until - I assume - "the vulnerability is no more"?

Please correct me, if I am wrong.

[Tomalrich]

I'm afraid not, Henk. The best published document that describes VEX can be downloaded from CISA's site herehttps://www.cisa.gov/sites/default/files/publications/VEX_Use_Cases_Aprill2022.pdf, although there's a very good documenthttps://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# drafted by Allan Friedman in 2021, which was unfortunately never published. I also want to point out that some of the people involved in the VEX effort (including me) have come to believe that VEX should really be an API, not a document that's distributed, for many reasons.

Tom Alrich LLC

312-515-8996

---

From: Henk Birkholz @.> Sent: Thursday, March 9, 2023 2:20 PM To: ossf/wg-vulnerability-disclosures @.> Cc: Tom Alrich @.>; Comment @.> Subject: Re: [ossf/wg-vulnerability-disclosures] VOTE - Adopt OpenVEX as project within the OpenSSF under Vuln Disclosure Working Group (WG) (Issue #125)

VEX is basically a... "VBOM", right? It tracks the life-span of a vulnerability, the document is updated and maintained as more details, mitigations, and remediation, until - I assume - "the vulnerability is no more"?

Please correct me, if I am wrong.

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

[henkbirkholz]

@tomalrich, could you help me out here a bit and highlight a section in https://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# that would contradict my...I'd say rather terse and simplified assertion?

[Tomalrich]

Sure, @henkbirkholz. The whole first section ("Abstract") is good, but this paragraph is the closest thing to a definition of VEX that I've seen. Again, I'll point out that some of us have changed our ideas about VEX.

The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other party to assert the status of specific vulnerabilities in a particular product. This class of security advisory will be of particular help in efficiently managing SBOM data for vulnerability management, by allowing both suppliers and users to focus on vulnerabilities that pose the most immediate risk, while not investing time in searching for or patching vulnerabilities that are not exploitable and therefore have no impact.

Tom

Tom Alrich LLC

312-515-8996

---

From: Henk Birkholz @.> Sent: Thursday, March 9, 2023 2:40 PM 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)

@Tomalrichhttps://github.com/Tomalrich, could you help me out here a bit and highlight a section in https://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# that would contradict my...I'd say rather terse and simplified assertion?

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

[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?

[costica11]

@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 - https://github.com/openvex/community/pull/6

[roywill]

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.

[dlorenc]

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?

Yes - that's the main intention here.

[camaleon2016]

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?

[henkbirkholz]

Sure, @henkbirkholz. The whole first section ("Abstract") is good, but this paragraph is the closest thing to a definition of VEX that I've seen. Again, I'll point out that some of us have changed our ideas about VEX. The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other party to assert the status of specific vulnerabilities in a particular product. This class of security advisory will be of particular help in efficiently managing SBOM data for vulnerability management, by allowing both suppliers and users to focus on vulnerabilities that pose the most immediate risk, while not investing time in searching for or patching vulnerabilities that are not exploitable and therefore have no impact. Tom Tom Alrich LLC 312-515-8996

@Tomalrich, (I hope this is not too off-topic for an issue with a vote label). How is your highlighted description not documentations created and maintained by several parties wrt certain vulnerabilities effecting certain products that are amended or augmented over time until the vulnerabilities are believably fixed (i.e., that all VEX documents about the vulnerability / product composites can state a "not affected" justification)? I might be missing something obvious here, but I still cannot see a contradiction to my test assertion above. What am I missing?

[henkbirkholz]

identifying non-exploitable vulnerabilities identified for components listed in an SBOM for a particular version of a product

Does that actually exclude exploitable vulnerabilities? I am not entirely sure, what OpenVEX is, if:

1. I cannot really tell what VEX is, or
2. I cannot really tell if OpenVEX actually is VEX or a superset (or a subset) of VEX.

[Tomalrich]

(if anyone would rather we take this discussion offline, please let me know)

VEX is basically a... "VBOM", right? It tracks the life-span of a vulnerability, the document is updated and maintained as more details, mitigations, and remediation, until - I assume - "the vulnerability is no more"?

@henkbirkholz, I think the biggest difference between the passage by Allan Friedman that I quoted and what you're saying above is that Allan is articulating VEX as the VEX working group has been thinking of it since 2020 (although, again unfortunately, we have published very little to document what we've been thinking) - i.e. VEX is a description of the product, not the vulnerability.

In other words, VEX (or VDR, for that matter) statements say, "Product ABC is/is not affected by vulnerability CVE-2023-12345", where this CVE is typically one that applies to a component in the product, revealed in a recent SBOM. Thus, the question VEX answers is, "Given that component XYZ is vulnerable to CVE-2023-12345 (as shown in the NVD or another vulnerability database), does it follow that Product ABC is also vulnerable?" I believe your statement is about the vulnerability itself, regardless of the individual products that may or may not harbor this vulnerability.

Tom Alrich LLC

312-515-8996

---

From: Henk Birkholz @.> Sent: Thursday, March 9, 2023 3:25 PM 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)

Sure, @henkbirkholzhttps://github.com/henkbirkholz. The whole first section ("Abstract") is good, but this paragraph is the closest thing to a definition of VEX that I've seen. Again, I'll point out that some of us have changed our ideas about VEX. The goal of Vulnerability Exploitability eXchange (VEX) is to allow a software supplier or other party to assert the status of specific vulnerabilities in a particular product. This class of security advisory will be of particular help in efficiently managing SBOM data for vulnerability management, by allowing both suppliers and users to focus on vulnerabilities that pose the most immediate risk, while not investing time in searching for or patching vulnerabilities that are not exploitable and therefore have no impact. Tom Tom Alrich LLC 312-515-8996 … ____ From: Henk Birkholz @.> Sent: Thursday, March 9, 2023 2:40 PM 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 #125https://github.com/ossf/wg-vulnerability-disclosures/issues/125) @Tomalrichhttps://github.com/Tomalrichhttps://github.com/Tomalrich, could you help me out here a bit and highlight a section in https://docs.google.com/document/d/10n3LA1wfD8MBwC-Od5INhd2OBStuW_dXmMoDiWL2rX4/edit# that would contradict my...I'd say rather terse and simplified assertion? — Reply to this email directly, view it on GitHub<#125 (comment)https://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1462761519>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVCDY6ZL7X6DMOPQNPPOAQDW3I55VANCNFSM6AAAAAAVUEWJZU. You are receiving this because you were mentioned.Message ID: @.***>

@Tomalrichhttps://github.com/Tomalrich, (I hope this is not too off-topic for an issue with a vote label). How is your highlighted description not documentations created and maintained by several parties wrt certain vulnerabilities effecting certain products that are amended or augmented over time until the vulnerabilities are believably fixed (i.e., that all VEX documents about the vulnerability / product composites can state a "not affected" justification)? I might be missing something obvious here, but I still cannot see a contradiction to my test assertion above. What am I missing?

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

[rjb4standards]

@Tomalrich

"In other words, VEX (or VDR, for that matter) statements say, "Product ABC is/is not affected by vulnerability CVE-2023-12345", where this CVE is typically one that applies to a component in the product, revealed in a recent SBOM"

That description of VDR is not accurate. A VDR is an attestation by a software vendor showing that each component of a product SBOM has been checked for vulnerabilities, and any components with vulnerabilities must be addressed by the software suipplier. Some vulnerabilities may be false positives, some may relate to earlier versions of components and are also false positives. Any real exploitable vulnerabilities need to be flagged and resolved before product release. After product release, any newly reported vulnerabilities also need to be addressed in the "online living" VDR document maintained by the software supplier. An example VDR is provided here a CycloneDX VDR example is provided here

[Tomalrich]

@henkbirkholz, I realize I didn't address your question, "I cannot really tell if OpenVEX actually is VEX or a superset (or a subset) of VEX."

I regard OpenVEX as neither one of those options. OpenVEX addresses a different use case altogether from what VEX (as conceived by the VEX working group under the NTIA and CISA initiatives) does. The purpose of OpenVEX is to identify vulnerability scan results that are false positives. The purpose of VEX is to identify component vulnerabilities that aren't exploitable in the product itself (which is a different type of false positive, of course).

I think OpenVEX is a good use case, and I'm sure it addresses the need for which it was developed. But it has nothing to do with SBOM or VEX, as those ideas have been developed (although not well documented, to be sure!) by the NTIA and CISA initiatives. I don't have a trademark on "VEX", so if OpenVEX wants to use that acronym, that's fine with me. But it's important to keep in mind that it's a very different use case, so it shouldn't be compared with the two existing VEX formats (both of which have a large number of maintainers), CSAF VEX and CycloneDX VEX.

I discussed this issue in more detail in thishttps://tomalrichblog.blogspot.com/2023/02/vexual-confusion-reigns.html blog post.

Tom Alrich LLC

312-515-8996

---

From: Henk Birkholz @.> Sent: Thursday, March 9, 2023 3:32 PM 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)

identifying non-exploitable vulnerabilities identified for components listed in an SBOM for a particular version of a product

Does that actually exclude exploitable vulnerabilities? I am not entirely sure, what OpenVEX is, if:

1. I cannot really tell what VEX is, or
2. I cannot really tell if OpenVEX actually is VEX or a superset (or a subset) of VEX.

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

[JLLeitschuh]

(Voting Member) +1

After quite a bit of discussion today with various parties, and reviewing the links above, I'm onboard with adopting OpenVEX under this working group.

[dlorenc]

(Voting Member) +1

After quite a bit of discussion today with various parties, and reviewing the links above, I'm onboard with adopting OpenVEX under this working group.

Thank you for taking the time to do the diligence and for expressing your opinion!

[dlorenc]

@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?

Putting my TAC hat on, that matches my understanding.

With my OpenVEX hat on, we've strived to make this legal and IP process smooth from the start so we don't anticipate any issues.

[annabellegoth2boss]

Re process, the next step would be a Sandbox Application and a PR for the TAC vote (Sandbox entry process).

[dlorenc]

Re process, the next step would be a Sandbox Application and a PR for the TAC vote (Sandbox entry process).

I'm not sure this is correct. As per the last TAC meeting, the TAC is not required for WGs to accept projects like this.

See this PR from @david-a-wheeler which attempts to clarify this: https://github.com/ossf/tac/pull/142

[AevaOnline]

Re process, the next step would be a Sandbox Application and a PR for the TAC vote (Sandbox entry process).

I'm not sure this is correct. As per the last TAC meeting, the TAC is not required for WGs to accept projects like this.

See this PR from @david-a-wheeler which attempts to clarify this: ossf/tac#142

In the last TAC meeting, I believe we noted that this procedure needs to be clarified. Uncertain whether the TAC needed to vote on a project joining under a WG, we none the less held a vote and had 6 YES 1 ABSTAIN to approve that project (I was the lone abstention).

(edited to amend)

On a procedural note, David's PR points out that:

A TAC member may ask for further review, at which point it becomes a decision item for the TAC.

which is what I did during the TAC meeting, and the TAC voted.