so what is VEX anyway?

[zmanion]

A vote (#125) about bringing OpenVEX into OpenSSF generated a lot of discussion. This thread is offered as a place to carry on the discussion if needed.

I'll start with this position: VEX is a structured way to convey the status of software components with respect to software vulnerabilities. Is this software affected or not? Say it in VEX. Do you publish vulnerability advisories or other information? VEX is an option.

I'm aware of at least three VEX implementations:

• CSAF(Red Hat uses CSAF for VEX)
• CycloneDX
• OpenVEX

Here are some definitions of VEX, three of them come from the community SBOM workstreams facilitated by CISA.

Vulnerability Exploitability eXchange (VEX) is a form of a security advisory where the goal is to communicate the exploitability of components with known vulnerabilities in the context of the product in which they are used. [1]

A VEX document is a form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities. [2]

A Vulnerability Exploitability eXchange (VEX) document must include the product’s status as it
relates to a particular vulnerability. [3]

Vulnerability Exploitability eXchange (VEX) indicates the status of a software product or component with respect to a vulnerability. A common VEX use case is to indicate that software is affected or not affected by a vulnerability.[4]

[rjb4standards]

I'm aware of at least two NIST VDR implementations:

• CycloneDX: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/CDXVEX/CDX14.xml
• REA's open-source VDR: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json

Both implementations adhere to NIST's Vulnerability Disclosure Report (VDR) data model in standard SP 800-161 RA-5

REA is prepared to withdraw support for it's own VDR format, if the industry can agree to support the CycloneDX VDR format.

Steve Springett created a side-by-side comparison of VDR vs VEX
https://owasp.org/blog/2023/02/07/vdr-vex-comparison.html

This article describes NIST VDR
This article explains why a VEX is unnecessary, if a company is already receiving CSAF Security Advisories and VDR's

[puerco]

The SPDX defects group is working on the next VEX implementation. I joined them back in January after I saw it for the first time in the SPDX general meeting and I plan to continue helping over there to ensure the SPDX VEX implementation meets the minimum requirements for VEX. /cc @tsteenbe @henkbirkholz

[henkbirkholz]

Thank you for a fresh and shiny bread crumb! ❇️

[rjb4standards]

@puerco
I look forward to your attendance at the spdx-defects meeting on Wednesdays at 3:00 PM Eastern time.
https://meet.jit.si/SPDXDefectsMeeting
https://spdx.swinslow.net/p/spdx-defects-minutes

The spdx-defects meeting minutes for Feb 1, starting on line 86, has some discussion of OpenVEX and it's relationship to other vulnerability reporting artifacts and their relationship to SPDX.

The V 3.0 vulnerability model is still under development, so this will be a good time to join.

[JasonKeirstead]

This situation has gotten even more messy with the news that LF itself is already making its own third VEX format. I didn't even know about that. So now we're talking about a fourth format?!

When VEX is so new that it is barely defined there is zero justification for all this format war. It is entirely counterproductive to actually enhancing real-world security.

[tracymiranda]

Which of the formats listed work both with CycloneDX and SPDX?

[rjb4standards]

Tracy,

All of the formats work with SPDX V 2.3 today: https://spdx.github.io/spdx-spec/v2.3/how-to-use/

[henkbirkholz]

Huh??? The LF is NOT creating it's own VEX format that I'm aware of.

The SPDX defects group (which is not equivalent to "LF") has stated historically that they were trying to align with minimum elements for VEX, and were waiting for the definition to settle down.

For the last year there's been a CISA working group working to define what the minimum elements for VEX are, that is trying to reconcile between the fork that CycloneDX did from the original CSAF VEX profile. OpenVEX work is building on the work done by that group. "OpenVEX documents are minimal JSON-LD files that capture the minimal requirements for VEX as defined by the VEX working group organized by CISA. The OpenVEX Specification is owned and steered by the community."

[1] https://github.com/puerco/openvex-spec#a-specification

There seems to be the rumor/notion/gossip that I did not personally checked out that "LF endorsed OpenVex". I am leaving it at that, but I assume that is the point here? I am not trying to be contentious! I am trying to understand the current friction in the scope of my perception, so this is a subjective remark. Please help me here and correct me, if I am wrong! I think that would help a ton.

[JasonKeirstead]

In the other thread, @stevespringett mentioned that SPDX was working on it's own VDR/VEX format. This was the source of my original comment.

#125 (comment)

(For the record, I don't think splintering this off into another GHE discussion was productive as now we have another container of discussion half of people do not see and we are going to be cross-linking between them all the time. What should have been done is the vote should be a Github Poll, and let the comments all be on it)

[rjb4standards]

This statement is leading to a belief that LF is endorsing OpenVEX, IMO:

"We have made significant progress in the last few years laying the groundwork for concepts like SBOM and VEX, but implementing them to drive adoption is the next step. To get them to be ubiquitous, we need standardization. Organizations coming together to champion and refine one specification, such as OpenVEX, is a going to yield a much more robust solution over time than those who choose to go at it alone and introduce multiple options into an already diluted domain." Kate Stewart, Vice President, Dependable Embedded Systems, Linux Foundation
https://www.chainguard.dev/unchained/accelerate-vex-adoption-through-openvex

[msmeissn]

FWIW there is also the OSV format ( https://ossf.github.io/osv-schema/ ) covering similar goals.

And you could express vulnerability info also in the original CVRF or CSAF 2.0 formats or even OVAL, albeit these formats are a bit clumsy to consume.

[zmanion]

OSV as an affected array but does not support VEX.

[oliverchang]

If I'm understanding the question here, indeed VEX is not a supported use case for OSV. OSV serves the sole purpose of communicating about vulnerabilities and affected versions in open source.

[rjb4standards]

If anyone is wondering "What is CISA's official position on security advisories and VEX"

1. Achieving Automation: Publish machine-readable security advisories based on the Common Security Advisory Framework (CSAF).
2. Clarifying Impact: Use Vulnerability Exploitability eXchange (VEX) to communicate whether a product is affected by a vulnerability and enable prioritized vulnerability response

These official CISA statements align with Allan's VEX video statements. OpenVEX is an attempt to manufacture something completely new and incompatible with all the other work in this area, including CSAF VEX and NIST VDR.

[JasonKeirstead]

@rjb4standards As a software supplier, yes, being able to issue a VEX alongside someone else's security advisory so that I can say "I am using library X but am unaffected by CVE 124556", in a machine-readable way, is exactly the idea. Again, as a software supplier, being able to do this would save us countless amounts of money per year dealing with these requests manually.... so yes.

The devil however is in the details, because it is only going to save the industry money and improve security IF that VEX is using a consistent reporting method in the entire ecosystem. If 1/3 the ecosystem is using format A and 1/3 format B and 1/3 format C and none of them work together with 100% fidelity, you've now tripled (or more) the complexity and cost, and perhaps eliminated the entire value proposition of even having VEX exist.

That is why I do not support the needless invention of new formats being driven out of a sake of vanity, or NIH syndrome, or unwillingness to join another groups phone calls, or any reason that is not driven by a very solid technical justification. I haven't seen any of that here at all, there isn't a singe technical justification for why this should exist other than "we want to", all the ones given in the presentation are non-sequitors or based on special interests, not technical.

[rjb4standards]

Art, what do you recommend that a software supplier publish when a software product is affected by a new vulnerability a "CSAF Security Advisory" (profile 4) or a CSAF VEX (profile 5) , or an OpenVEX artifact?

[msmeissn]

I think both need to be done, especially as security advisories might have multiple CVEs fixed and VEX is usually mapping to 1 CVE.

For SUSE we publish both a "security_advisory" based notices (CVRF and CSAF "security_advisory" format), and also CVE index VEX style information in CVRF and CSAF "csaf_vex" format.

[rjb4standards]

I had an enlightening conversation yesterday. Some people think this debate is all about format wars. It's not, IMO.

This is about knowing "the rules" if you want to sell software to the US Government. An OMB memo issued on September 14, 2022, M-22-18, clearly shows that parties interested in selling software to the US Government need to follow NIST Guidance.

VEX is NOT listed under NIST Guidance.

VDR is listed under NIST SP 800-161 RA-5.

[JasonKeirstead]

What the US government decides to do or not do is not my primary concern. I am trying to make the entire industry work better, to protect society - not just the US government. To do that requires us to work together, not fight each other over silly issues like "heaviness" of JSON formats that we want to be consumed by machines and never even read by a human.

The whole VDR vs VEX thing I think is just needless additional confusion. When you take the technical implementations out of the mix, and just read what a VDR is and read what a VEX is, they are trying to do exactly the same thing, and it is all just semantics. You can actually use VEX to create a VDR - this is actually what CycloneDX is doing today. IMO, NIST did the industry a disservice inventing & pushing a new word for a concept that already existed. The ISO standard for VDR is also lacking 1/2 of VEX because it does not give a simple way to say 'I am not susceptible to this vulnerability, and here is why', which is a primary use case of VEX. however ironically, if you read the NIST best practice - they actually suggest this information be part of a VDR! IE - when you actually read all the text - the ISO minimal fields for VDR do not even meet what NIST is asking for... NIST VDR actually asks for a VEX! It is so needlessly confusing.

[rjb4standards]

Thanks for responding Jason. Does this represent IBM's official position regarding VEX and VDR?
As Allan Friedman has said many times, a VEX is a "negative security advisory".

A VDR is an attestation by a vendor showing they've checked each component of an SBOM for vulnerabilities.

Your description of VDR is completely inaccurate. An exploitable flag (Y/N) indicates if a product/compoent is vulnerable, as you can see in the VDR linked above.

[JasonKeirstead]

a) Nothing I ever say represents IBM's official position on anything. IBM also has no software offerings in this space and as such it is a fairly unbiased opinion.

b) A Y/N flag is insufficient information because it is missing all the required context.

c) I continue to assert that "an attestation by a vendor showing they've checked each component of an SBOM for vulnerabilities.", has always been one of the use cases for VEX, since it was envisioned (which was long before NIST invented the word VDR). We've been talking about this in circles since 2016-2017. It is not a new idea.

[JasonKeirstead]

To eliminate any possible confusion in what I am saying - your REA VDR, is also a VEX, in my opinion. It conveys the same information you would want in a VEX. I don't see any actual difference in these things besides semantics and naming. Any VDR format is likely also a VEX format - these are not apples and oranges, it is just two different species of apple.

[rjb4standards]

I understand, this is your personal opinion @JasonKeirstead

I know that IBM has expressed an interest in the software supply chain space.

REA's open-source, free to use VDR is exactly what it says it is, a VDR, following NIST SP 800-161. I'm 100% confident in this assertion.

VEX is a "negative security advisory" identifying products which are NOT affected by a vulnerability. The ground truth supporting this description is readily available in this video with Allan Friedman and Thomas Schmidt at the 13:00 mark. No matter how many times you try to paint VEX as something different - this will remain the ground truth on VEX.

[JasonKeirstead]

Dick - We don't need to keep arguing here.

• VEX contains both positive and negative assertions - just like a "VDR" does... I suggest you re-watch the video you linked because it is actually discussed, with an example. Again, no need to argue about this because none of it is worth arguing about. I know & respect both Allan and Thomas - but neither of them "owns" the definition of VEX, neither does OASIS, or anyone else. VEX is just a concept. Just like VDR is just concept, it is a best practice that NIST published in a document - these are abstract ideas, neither of them are standards. No one "owns" the definitions of these things, there is no NIST publication that officially defines what a VDR is... if there is, please share it. Simmilarly, there is no standards body at all that defines what a VEX is, CISA is looking to publish some guidelines, but CISA is not a standards body either so whatever gets published still won't define 'VEX' as a thing, it will simply define a CISA point of view. Anyone can claim anything is a VEX, because no one can say otherwise right now.

[rjb4standards]

I agree Jason, we don't need to continue this debate. Based on recent voting, it appears OpenVEX will move forward under LF.

I recommend that anyone wishing to sell software to the US Government consider following NIST standards/guidance. A Federal Register notice will be coming shortly with more explicit requirements regarding attestations in support of OMB M-22-18..

[zmanion]

Closing, the OpenVEX vote has been decided (#125), CISA will be publishing a community-developed VEX minimum requirements document, everyone is free (or predetermined) to discuss, debate, and define VEX.

[rjb4standards]

Art, When you say CISA will be publishing the VEX document, does this mean the VEX document will be subject to the same approval process required by other CISA publications, such as the ICT_SCRM Task Force guidebooks? Thanks, Dick Brooks Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™ <http://www.reliableenergyanalytics.com/> http://www.reliableenergyanalytics.com Email: ***@***.***> ***@***.*** Tel: +1 978-696-1788 From: Art Manion ***@***.***> Sent: Wednesday, April 12, 2023 11:54 AM To: ossf/wg-vulnerability-disclosures ***@***.***> Cc: Dick Brooks (REA) ***@***.***>; Mention ***@***.***> Subject: Re: [ossf/wg-vulnerability-disclosures] so what is VEX anyway? (Discussion #127) Closing, the OpenVEX vote has been decided (#125 <#125> ), CISA will be publishing a community-developed VEX minimum requirements document, everyone is free (or predetermined) to discuss, debate, and define VEX. — Reply to this email directly, view it on GitHub <#127 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFI3NELJ5NTVFUZHIDLIO3XA3FYVANCNFSM6AAAAAAVWZRHBA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[zmanion]

Art, When you say CISA will be publishing the VEX document, does this mean the VEX document will be subject to the same approval process required by other CISA publications, such as the ICT_SCRM Task Force guidebooks?

I don't know the approvals processes, but Minimum Requirements for Vulnerability Exploitability eXchange (VEX) was published a couple weeks ago.

Quoting from that document, I propose that the answer to this discussion is:

Vulnerability Exploitability eXchange (VEX) indicates the status of a software product or
component with respect to a vulnerability. A common VEX use case is to indicate that software
is or is not affected by a vulnerability.

...machine-readable collection of information conveying the status of products or components with respect to a vulnerability.

[rjb4standards]

@zmanion Art, I've read the VEX minimum elements document, which answered my question:
"This document does not represent official CISA policy, nor does the document impose or mandate compliance"

No approval is required for a document that does not represent official CISA policy, from what I understand.

[stevespringett]

@zmanion I know you marked this as answered, however, many people have come to me with a question I cannot answer. That is, why has CISA published two documents that contradict VEX minimum requirements?

See: https://www.cisa.gov/sites/default/files/2023-01/VEX_Use_Cases_Aprill2022.pdf

In the updated Minimum Requirements doc it states: "This version of the VEX data element requirements is 1.0.0". So what was the version of the previous minimum requirements?

So the answer to "so what is VEX anyway" will depend on what CISA doc the user is referencing. I think CISA needs to stop moving the goalpost and confusing the community.

[rjb4standards]

@stevespringett I agree that a small faction within CISA is creating this confusion. The key is "this is not official CISA policy", which IMO just creates more confusion, especially when you have Eric Goldstein writing blog posts endorsing VEX, which is "not official CISA policy".
https://www.cisa.gov/news-events/news/transforming-vulnerability-management-landscape

Radical transparency is being manifested by radical chaos in CISA. I don't blame Director Easterly for this mess, she is going to battle with the Army she has, not the one she needs to create a cohesive and collaborative cybersecurity team.

[zmanion]

@zmanion I know you marked this as answered, however, many people have come to me with a question I cannot answer. That is, why has CISA published two documents that contradict VEX minimum requirements?

See: https://www.cisa.gov/sites/default/files/2023-01/VEX_Use_Cases_Aprill2022.pdf

In the updated Minimum Requirements doc it states: "This version of the VEX data element requirements is 1.0.0". So what was the version of the previous minimum requirements?

So the answer to "so what is VEX anyway" will depend on what CISA doc the user is referencing. I think CISA needs to stop moving the goalpost and confusing the community.

I don't think there was any VEX requirements versioning prior to 1.0.0. Yes, the Use Cases document from April 2022 includes a brief Minimum Data Elements section, but the Minimum Requirements document from April 2023 goes into much more detail, and does not contradict the older guidance. I consider "moving the goalpost" to be a natural part of development, especially in early stages.

I recommend following (or at least starting with) the most recent guidance, the Minimum Requirements 1.0.0 document.