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]

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

A VEX document, i.e. a negative security advisory, is burdensome and unnecessary, for consumer risk assessments

I also recommend reviewing the OWASP side-by-side comparison of VEX and VDR

[Tomalrich]

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: First, there is no approved CISA document called "Minimal Requirements". When Chainguard presented to this group more than a month ago, there was only a draft document with that name, that was still being debated by the VEX working group. This group is a collection of individuals convened under CISA's auspices, but is in no way a function of CISA. CISA has no regulatory authority for the private sector and can't define "requirements" for any organizations except federal agencies (of course, this document doesn't apply to federal agencies any more than it does the private sector). The document just describes guidelines that are the personal recommendations of some members of the VEX working group. The document was approved by the working group two weeks ago, and now has to go through intensive vetting by CISA's lawyers, which may take a couple of months. Only then will it be an official document. CISA may well decide that they don't want to allow a document to be published under CISA's logo with a title like "Minimum Requirements" - so the document may still be amended or killed altogether. I want to point out that this document contradicts in several ways a document published a year ago by the working group, called "VEX Use Cases" (available at cisa.gov/sbom). Second, the use case that "OpenVEX" addresses - removing false positives from vulnerability scans - has nothing to do with the primary VEX use case, which is identifying non-exploitable vulnerabilities identified for components listed in an SBOM for a particular version of a product. I personally like the OpenVEX use case and I don't care whether or not they use the term "VEX", but this has nothing to do with the NTIA/CISA VEX program. I've written two blog posts on OpenVEX, available at "Tom Alrich's Blog". I will write a third post soon.

[dlorenc]

I'm not a voting member of the WG and my support is probably obvious, but non-binding +1 from me!

[Foxboron]

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.

[trevrosen]

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.

[david-a-wheeler]

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

[dlorenc]

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.

[rjb4standards]

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.

[JasonKeirstead]

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.

[costica11]

"like that OpenVEX avoids taking sides in the SBOM format debate"

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

[mrutkows]

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.

[rjb4standards]

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. I will say, the CycloneDX community is very engaged and supportive of implementers. The SPDX community is also very supportive. You can't go wrong choosing either SPDX of CycloneDX.

[trevrosen]

@costica11 I'm merely pointing out that SBOM format agnosticism is a stated design goal in the spec's FAQ. 😄

[tpletcher-hpe]

+1 on this proposal.

[rgreinho]

+1 👍

[anvega]

VEX is key to automating the vulnerability remediation lifecycle, and OpenVEX is a step forward in that direction, +1.

[anoncam]

I'm not a voting member of the WG and my support is probably obvious, but non-binding +1 from me!

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.

[rjb4standards]

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. A NIST VDR is product based, it shows the vulnerability status of each component in a software product SBOM on an on-going basis (living document)

[SantiagoTorres]

+1! I'd love to see more tooling and OSS innovation around VEX through OpenVEX!

[trishankkarthik]

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.

[JasonKeirstead]

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

[stevespringett]

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.

[dlorenc]

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.

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

[brooklynrob]

@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

[brianbehlendorf]

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: https://github.com/ossf/wg-vulnerability-disclosures/issues/125#issuecomment-1461217525 You are receiving this because you were mentioned.

Message ID: @.***> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[brooklynrob]

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

[brianbehlendorf]

Thanks Rob. I'll follow up on this in another forum, to return this topic to OpenVEX as a project within the OpenSSF.

[dlorenc]

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

@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

Thanks for calling this out! I've converted it into a PDF and attached it here.

OpenVEX.pdf

[tracymiranda]

+1 we need solutions in this space designed with the needs of open source projects as first class citizens. While there are pre-existing solutions, IMHO they have hit local optimums and have not achieved broadscale adoption, especially for open source projects. OpenVEX is very nascent but has already achieved traction e.g a new Rust implementation for OpenVEX documents openvex-rs

[rjb4standards]

REA has gone on the record stating it will withdraw its open-source VDR schema IF the community coalesces around the CycloneDX VDR standard. If you want an open-source standard to communicate vulnerability information at the product SBOM component level then support CycloneDX VDR, then we can all focus our energies on one common solution for vulnerability reporting at the SBOM component level and stop wasting time creating conflict, where none needs to exist.

[colek42]

+1 for openVEX adoption into the OpenSSF

[mnm678]

+1 for OpenVEX adoption.

[rjb4standards]

@ByteHackr Is this Red Hat's official position on OpenVEX? Does this mean Red Hat will be supplementing it's CSAF Security Advisories, showing software that is affected by a vulnerability, with an OpenVEX artifact showing software that is not affected also?

[kaniini]

I don't really care if OpenSSF brings OpenVEX in or not, but I know carpetbagging when I see it.

With that said, OpenVEX was originally designed with the intention that APK distributions (such as Alpine and Wolfi) use collections of OpenVEX attestations as a replacement to the current SecDB format that was originally advanced by Alpine.

The project should be considered from that perspective (security advisory disclosure), and it should be noted that VDRs as provided by CycloneDX or CSAF or whatever other standard are entirely unfit for that purpose, being basically the exact opposite of what VEX is supposed to provide.

I also think that brigading real work done by others to try to standardize these types of feeds is not a productive way to promote CycloneDX or CSAF or any other "competing" standard.

[sudo-bmitch]

+1 this fits nicely in workflows I'm building and cleanly separates the static SBOM content from the dynamic VEX reports.

[yogeshnmittal]

No from me.

[balteravishay]

+1 on the adoption of openVEX to the OSSF. its a step forward to VEX adoption by the community.

[u269c]

+1 (voting member)

My rational is that this is a nice, minimalistic way to offer VEX statements which will be (already is) easy to adopt for OSS maintainers, and the VulnWG can help promote this as part of their Mission.

While other broader efforts like CycloneDX, SPDX and CSAF do include full or partial VEX statement supports, a dedicated solution here will be more interesting to smaller projects and developers. We are focused on helping the OSS communities, and if OpenVEX can help raise the general security bar w.r.t. vuln scanning, I think it makes sense to have the project live under the VulnWG.

I understand some folks are upset about the splitting of the standards, the "why create a new solution; it'll confuse folks" and that OpenVEX folks should have just reached out to CycloneDX and SPDX and CSAF to broaden the whole thing. Regarding the CISA VEX publication, we had Art Manion, lead editor on it, discuss this during the Feb22 VulnWG meeting. We agree with him.

On collaboration and integration, the OSV project's various ecosystems adoption as mentioned by Oliver, lead of the OSV project, in the APAC meeting a few weeks ago also coincide with a joint effort more than a splitting here. OpenVEX is not perpendicular to that effort; we see a good collaboration potential under the same roof. Here is OSV's opinion on OpenVEX as well.

This project would be a good fit in the OpenSSF's vulnerability working group.

[rjb4standards]

This segment from Art's video says it all: https://youtu.be/oZO3rg9mL1w?t=1098

[brooklynrob]

@rjb4standards

"There is no voting procedure, there is no official rules ... we're sorta of making it up as we go" is not going to be comforting for CISO orgs in investment banks to hear, as I'd imagine in many other industries, especially highly regulated ones, working on software supply chain security.

Isn't creating and enforcing proper governance a primary intended use of membership dollars? I know there has been a lot of hard work done on just this - governance - by the LF teams, including in and/or around the community specification standard. @mindthegab, @copiesofcopies, and I, among others, invested many months working on governance for FINOS, which is now in the LF, circa 2018, including and especially around voting procedures, and my impression of the wider LF was that governance was something that is pretty buttoned up.

Surely this effort can't really be a case "making it up as (they) go", particularly given how critical and high profile (even the White House is involved) this effort is.

[lehors]

@u269c Who's "we" in your comment? (This is a genuine question - I realize that this thread is a bit hot and people are getting a bit testy unfortunately.) Thanks.

[rjb4standards]

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

[dlorenc]

"There is no voting procedure, there is no official rules ... we're sorta of making it up as we go" is not going to be comforting for CISO orgs in investment banks to hear, as I'd imagine in many other industries, especially highly regulated ones, working on software supply chain security.

Isn't creating and enforcing proper governance a primary intended use of membership dollars? I know there has been a lot of hard work done on just this - governance - by the LF teams, including in and/or around the community specification standard. @mindthegab, @copiesofcopies, and I, among others, invested many months working on governance for FINOS, which is now in the LF, circa 2018, including and especially around voting procedures, and my impression of the wider LF was that governance was something that is pretty buttoned up.

Surely this effort can't really be a case "making it up as (they) go", particularly given how critical and high profile (even the White House is involved) this effort is.

Please note that @zmanion's comments here referred to the CISA SBOM WG that produced the "Minimum Requirements for VEX" document that will be published soon. That group is not affiliated with the LF or OSSF. The OpenVEX project uses the Community Specification process for decision-making.

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

[annabellegoth2boss]

(Voting member)

Three questions:

1) Is what's being proposed to join as an OpenSSF project just the specification (under openvex/spec), the all the repos in the OpenVEX GitHub org?

2) What project stage does this want to join at?

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

[dlorenc]

• Is what's being proposed to join as an OpenSSF project just the specification (under openvex/spec), the all the repos in the OpenVEX GitHub org?

All the repos.

• What project stage does this want to join at?

Sandbox would be fine.

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

I'm not sure how to answer this authoritatively, but there has been no official "project-to-project" collaboration, although many of the contributors to OpenVEX are also involved in those other projects. The specification was designed to be SBOM-agnostic, and work with both (and any other) SBOM formats: https://github.com/openvex/spec#sbom-agnostic

[camaleon2016]

I vote yes! +1 for me.

[rjb4standards]

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

[dlorenc]

@rjb4standards - please take this discussion elsewhere. It's off topic and inappropriate for this forum.