 Okay, Adolfo is going to go over VEX and how you would show, you know, maybe a vulnerability is affected and then maybe you do more research and you realize it's not affected. He's going to cover how you would show those changing statuses of relationships. Thanks. All right. Yeah. So let's go a little bit on two VEX. So for those who are not familiar, VEX, which stands for Vulnerability Exploitability Exchange, is a way of conveying the actual impact that a vulnerability has on a given piece of software. Because once, as we were seeing S-Bomb information starting to increase and flow even more, so do the number of false positives and other information detailing, like starting to light up security dashboard shortcuts, right, because you have more visibility into your supply chain and those components start to show up, especially, and this is especially true for, because sometimes when you ship software, for example, things like base images who include software that you don't really need, they start to light up and flag vulnerabilities that may not necessarily impact your piece of software. So to understand this, I want to give a short example. So the first thing I want to point out is if you saw in Rosa's previous examples, the security profile is about conveying the disclosure of security information. So you have to think about the information flowing regarding to security as flowing different cadences. So the first one is you have the S-Bomb, which is supposed to be static, because once you publish a piece of software, it's supposed to never change, right, because if you issue a new piece of software, it needs a new S-Bomb because it's a different thing. And then on top of that, you have the security information. You have a vulnerability, and when that's released, it has a set cadence, it should also not change, but the assessments of those vulnerabilities start to change. More information gets known, more people are looking at it, are issued in opinions of that vulnerability, and it starts to change. And the same is true for the impact of the vulnerability with a given piece of software. So I'm going to retake the example of Bob's browser. I think I took a subset of that by centering on Bob's browser. So Bob's browser contains a version of Carl's compression engine. So in this case, what's going to happen is that someone is going to find a CVE that affects that it's contained in Carl's compression engine. So if Carl's compression engine has that CVE, that means that at some point Bob's browser is going to start to get flagged as vulnerable. So the first thing that's going to happen, and the vex author, which in this case, you should have an authoritative source of vex information, is going to be Bob, right? Because if you think about it, if you're running Bob's software, then you can pretty much give him, you're already trusting him of understanding what he's shipping. And he may understand the impact that this CVE has on his browser, which came through this dependency here. So the first thing that a vex author might do is issue an under investigation message. In vex, the idea of vex is people start sending down-the-wire messages of the known impact of vulnerability that has on software. And if you think about the SPDX, the great thing about the SPDX is that it has all of these wonderful sets of relationships that let you communicate how all of these pieces relate to each other. So what we did in the security profile is overload, I don't know if that's the right word, but supercharge might be better, those relationships with more information to convey the vex status, just as we did with the security assessments. So once the CVE hits and it gets published, Bob starts looking into it and the first thing that he should do is inform people that, okay, I'm looking at this vulnerability and how it affects my software. And then after that, he may find, so the under investigation relationship has a field where it lets you point, I'm looking at this CVE in my browser, but assessed looking at it because I know it's contained in Carl's compression engine V31. And then the next one is Bob will determine, okay, I'm affected. He sends the affected message down-the-wire and people can react to it. So you can enact policy because all of this is machine readable. So if your idea is, okay, I should patch, I should take care of it in my own hands, this is your starting message that you should start acting. Or the next one is, okay, let's say that Bob goes to Carl and says, Carl, can you patch the vulnerability? Carl may say, well, I'm the lonely maintainer in Nebraska. I cannot do that just now. So Bob may issue, like, take action and fix it by himself. So he releases B221 with mitigation for that, for the CVE containing Carl's compression engine. But if you think about it, and he's still shipping this as a vulnerability, as a component, it may still show up in the scanners because it's still containing there. Even though Bob has mitigated it in his piece of software, the CVE is still contained in his software. So what Bob issues is a new message that says, even though I'm shipping you Carl's compression engine with, which is affected in our CV, I have mitigated it. And in the, it's not like the security document in SPDX, I'm marking it as not affected. And so this is the way that VEX conveys messages down the wire. And so VEX is defined by a working group organized by CISA from the US. And this means that now SPDX joins a number of VEX implementations. So the working group defines VEX as an idea, as a spec of specs. And SPDX now joins Open VEX, CISA, and Cyclone DX as VEX implementations. And the, as we are just releasing it, the final VEX specification or document defining what the minimal requirements for VEX was released in January, SPDX joins Open VEX in being the only two fully compliant implementations of VEX. So the other two implementations, you can go from there to VEX, but not the other way around because you lose information, which is critical for a proper functioning VEX implementation. So that's the base of it. So, and this is one, and okay, so I'm going to turn it over to Karen, and, oh, yeah. So this is the point. This is the laser, and this is the pointer. Yeah, CVE reporting, right? But there are some time, some defects in the software. How do you intend to use VEX? So you can communicate some un-patched software. I'm thinking more on, not from CI, but more on availability perspective, like, you know, buffer overflow, et cetera, that a software developer can include. Have you guys thought about that? I'm sorry, I missed half of the question. Okay, the question is, this whole schema relies on CVE reporting, so you can include CVE. Are there an option where software developer can include some software defects that can be related to end user using VEX? It can extend beyond CVEs. It's been designed to work with other bug systems that are out there. So as long as you've got, that's why we call the group defects as opposed to vulnerabilities, because there are defects out there that we need to report in on. And so this is a mechanism that should extend there. But if it doesn't, we want to know this right now. This is why we're bringing this stuff forward. Yeah, and the other thing is VEX is not based around a software version. It's based around the product. And so it has this level notion around product. So product can be an SPDX package, but also a bigger software package. And it also has a vulnerability, just plain vulnerability. It's not tied to a CVE. It can also, I think if I remember correctly, the definition that we added to the vulnerability is any vulnerability that can be tracked that is registered in a tracking system. So if you have an in-house tracking system, it can point to that. If it has a reference, you can relate to it. That's where you can use the security external identifiers to say that I am the agency that's who assigned this ID for this defect. And then you can also use the external references to point to information about that defect. Thanks. It's a more general question to all the presenters. Can you please upload your presentations to the schedule? Thanks. Thanks. Can you go back to the slide with Bob and Carol for a second? I'm trying to get my understanding of the document flow improved. That's the one. So today, if I look at a 2.3 implementation, I created an SBOM. I have the description of what's in that particular application. So I've got Bob's SBOM, it includes Carol. I understand that I've got one document that was created. With VEX, am I effectively having a series of SPDX documents that are going to be part of the flow? And if so, what out of the original SBOM contents are part of that flow? So in other words, am I overloading a system that is just starting to figure out what SBOMs are all about with this additional data set that now needs additional mapping? So I'm just trying to get that clear in my head. Thanks. No. Ideally, you could issue just the document with the, so VEX and SPDX is our relationship. So you could issue just that document with the reference for the vulnerability and the reference for the product. Just the, even the subcomponent is just the identifier. So we only need those three in the document. So you start shipping those. So then I have an SBOM document itself that represents whatever was shipped. So Bob's 2.2, and now I'm going to have a number of relationship documents that will refer back to that original SPDX document. Exactly. Which should remain static because it's the same piece of software. Okay. And then when Bob creates 2.2.1, so then when Bob creates 2.2.1, well, there might be a component change if he did patch Carol's engine, or maybe there was something else that came along for the ride as part of the mitigation effort. But theoretically that SBOM is close enough, but it's still a mapping from that point forward. Exactly. I mean, in that case, it's a new SBOM because it's a new piece of software. So it's an additional. Yeah. Like Rose said. Yeah. I was just going to say that you can have multiple relationships and multiple vulnerability elements in one security profile SBOM. So you don't have to create a new quote, unquote document for each relationship, security relationship or each vulnerability. So that then allows me potentially to create a vulnerability mapping back to a previously ship piece of software that is using an older version of SPDX. Yeah. I don't, to SPDX 2.3. Okay. Yeah. So you can point to a 2.3 document, but you'll. Cool. Thank you. And not only that, you can also point to like the idea of Vex is when once you have like once we start getting like Vex processors, you can compile off that all of that information to piece together the impact story, which may not necessarily come all from SPDX. It can come from the other formats as well.