 So, the security profile is designed to, as you would guess, communicate security information. And so probably the biggest part of that is communicating vulnerabilities in software. So if you know that there's a CVE that exists in a package, you want to communicate that somehow. And there's kind of two ways that you might want to talk about this. You might want to associate the vulnerability with a specific element. So this vulnerability is found in this package. You also probably want some way to communicate the severity of that vulnerability and the impact or the exploitability of it. And there's different ways, different ways that you can rate the severity, and we've built in support for those different ways. But maybe you just want to link to external vulnerability information. So this might be in relationship to a particular CVE, or maybe you want to include security information in a security relationship. So you might want to link to some sort of security advisory. So this has support for CSAF, Cyclone DX formatted security information, OSV documents, and VDRs per the NIST Executive Order 14028. You also might want to include information about a security fix for a CVE. So whether that's a code fix or a patch. And then maybe you have information that doesn't fit into fix or vulnerability. You can use security other, which is kind of just a catch-all for including any unspecified type of security information. And then we also have a way to assert the status of a vulnerability. So there's built-in VEX support here, and Adolfo's going to talk more about VEX if you've never heard of it, or you're not sure what it is. He will cover that. It stands for Vulnerability Exploitability Exchange, and it's just a way of communicating whether packages are actually vulnerable to CVEs that are associated with them. Okay. Is that the last one? Okay. Well, my image is not showing, but that's okay. So these profiles, they use the core profile and then inherit from it. So a vulnerability is a security element. It inherits from core's element thing, and a weakness, yes, a vulnerability is an element, and it has a published time, modified time, and withdrawn. These are all optional. You don't need to include them, but it's metadata that you can include about a vulnerability. A vulnerability might also have an external reference or an external identifier, and it may have one or more of these things. So we'll go over an example of what that looks like. The security profile also adds security-related external reference types. So as we kind of discussed, a security advisory, which is some sort of published security advisory defined per this ISO here by the U.S. government, and then a security fix or a security other. My goodness, I think we're going to have issues. So the security profile uses relationships just like you would in core. So you're going to, from an element, there's going to be some type of relationship with a relationship type to another element. And especially in the security profile, this could be an actor of some sort. And we'll go over that. So in order to communicate assessment of a vulnerability, which is essentially severity, we chose to use relationships. And that's because you can kind of model metadata using a relationship or a property, but relationships are for things that are changing or may change more frequently than something like a property would. So we have this vulnerability or vulnerable assessment relationship, and then inheriting from that are kind of these different metrics for scoring a vulnerability. So CVSS v2, CVSS v3, EPSS, et cetera. And then we have this VEX-vulne assessment relationship. And inheriting from that are the different types of VEX status relationships. So there's fixed, not affected under investigation and affected, and it also will go over those in just a bit. We also added two core security-related relationship types. So these are used in a number of ways. You'll see something like has CVSS v2 assessment for, that's going to be used in relationship with the CVSS v2-vulne assessment relationship. But there's also relationships like has associated vulnerability, which simply says that there's a vulnerability that exists and in some way it's associated with a software artifact. This does not mean that the vulnerability affects the software artifact or it does not affect the software artifact simply that there's a known relationship published there. We have more. So fixed by, found by, published by, reported by, republished by, these are relationships that you might use to associate an actor or with a vulnerability element. And so this is all in the model on GitHub. If you want to look at more of those definitions, there's also these effects does not affect fixed and under investigation for, those are VEX relationships that you'll use for VEX relationship elements. So I wanted to go over an example. This is from NIST, I think. They have like an SBOM document and this is just a really simple example. We're going to assume that Acme application and Bob's browser, all of those are packages. So Acme application is what you would typically think of like, oh, this is the top level software. I want an SBOM for that. And it has all of these dependencies included in it. But we're going to simplify this even more since code blocks, there's only so much that fits on a screen. So we're going to have this top level Acme application and it contains Bob's browser and you could use core to model this relationship on the screen. So Acme application, it contains Bob's browser. Maybe you would use the depends on relationship that depends on how you want to model this. But this could be modeled in core. But now if we say that Bob's browser has a vulnerability, we're going to use a security profile to model this. So the things highlighted in orange are security profile specific things that I've kind of talked about in this presentation. So we would create this vulnerability element and we're going to say it's CVE 20231234 and this is all kind of made up. So we'll just say, you know, there's an ID, a summary, a description for this vulnerability because it is an element in the security profile and then we have these external identifiers. So look, I have a pointer here. So this external identifier type is a CVE. That's the ID assigned to this element. There's the locator for it. Okay. No, I lost my pointer. There's locator for it and issuing authority. And then you can, as I said, you can have multiple external identifiers. So maybe you also have a security other external identifier. This one in particular is coming from a GitHub advisory and you could list as many as existed for that CVE element that you created. And then you could also have an external reference. And so this is a security advisory external reference to the NIST vulnerability detail for this CVE and this is, you know, a vulnerability element that can contain all of this metadata about the vulnerability. This is a continuation, so I just chopped off all those external identifiers but let's assume that they were still in this vulnerability element. We would then use relationships to associate the vulnerability with a subcomponent or with a package. So, you know, we have this relationship. We have this relationship. We create an ID for it. And then this is just kind of a high level has associated vulnerability. That's the type I was talking about where we say there is a vulnerability that says it's in this package, Bob's browser, but we don't know anything more about that. We don't know whether it affects it. We don't know the severity. We just know that there is a CVE that is associated with this package. And so we would use relationships to say something like that. Yeah. Sure. So how this works in practice, this vulnerability, it is outside of the SPDX itself. But there is a pointer in the SPDX that points to the CVE. So who is responsible for putting that in? Is that the developer that puts that in? Or is there within the organization, such as my organization, if I'm ingesting that, would my internal software assurance people or someone like that modify the SPDX to point to that CVE? Or how does that work in practice? So then the responsibility is the, so there's two ways. So I, as the consumer, could amend the SPDX. Or I, as the developer, could also append the SPDX. Okay. Okay. Cool. Thank you. So more code that will make your eyes hurt. I apologize. This is a way to assert an assessment for a vulnerability. So this is saying that I am asserting a severity for this CVE. So to do that, we're going to use this CVSSV3 Vulna Assessment relationship. Then we're going to create a relationship element. The relationship type is the associated has CVSSV3 Assessment4. It has a severity field, a score, a vector, and you would fill that in. And then from is going to be the top level package that contains a subcomponent with the vulnerability. So we're saying that top level ACME application 1.1 has this vulnerability with this severity. And then the assessed element is a security profile piece of metadata that basically indicates which subcomponent has this vulnerability. So you can kind of see the hierarchy from that diagram that we started with, where the ACME application is that top level component. And then this Bob's browser 2.2 is the subcomponent, which actually contains the CVE. And then just like the vulnerability element we created, this CVSSV3 Vulna Assessment relationship element might also have external relationships, it might also have an external identifier included one here just for an example, but it also might not. But you would use it in the same way as the previous relationship. And then I also included a way that you can show who published this severity score. So you would use a relationship for that with the published by relationship type from the security profile. So we're saying from this CVSSV3 CVE relationship, and then the actor is this agent sneak, that's who assigned the severity of the vulnerability, and maybe it has a start time of when that severity was established.