 All right, security profile. So basically, a long wish has been to communicate basically security related information inside, well, not inside a little bit, with your Aspom data. And so that's what we're working on in the defects group. So yeah, this much confused people why it's not called the security group. It's actually the defaults group, which is the security is the first bit of defects that we're tackling. That's why the group is called defects. There's more things that we're working on, but security is the first thing that we basically start tackling. Basically, we've looked at four major use cases which like discovery and disclosure, severity, risk and remediation. And so again, there's luckily a lot of standard models on how security information is being shared. So we're not reinventing the wheel, we're just trying to figure out, okay, these are kind of the models that people are used to. How can we translate them into an Aspom specification? And in a way that is very powerful, but also on the same side where I was looking at a lot is how can we do it that it's not overbearing? So there are other specs that really, a well-named name, but input, I got one of the specs with 1700 fields and everybody wanted to have every field for every security use case in there. And then we said like, no, let's first focus on the core stuff that we really, really get everybody really, really wants to communicate and then we'll see it on. And so these were the major four ones. And then we have also now new things like security assurances and integrity. So you can really link as well, but let's me go dive into all the things. So we added so-called external refs. Is everybody familiar with what I say in external ref? External ref is basically external reference. So from your Aspom, you can point to other stuff. So we added 12 new ones of those. So you can now basically say like, oh, I did a security assessment. Here is the proof for that. Or I used this internal security tool where I have analysis. Here you have a link. The idea is basically that if you go to your security lifecycle and you have evidence in various systems, you can now put a link to it. And that's very useful if you have, for instance, have internal Aspoms and you wanna know, hey, did this product actually go to all of the stages before it went out of the door? But now you can keep all the evidence. So if somebody wants to review it, fire to release, you have everything. This is quite common. A lot of companies make internal Aspoms for internal communication. And then they have the one that goes to the customer. So now you can track all of that information internally and then you can exactly know like, oh, did we do this assessment? Do we have evidence for that? Did we do a risk assessment? And instead of having this in a separate word document or having to have an entire system, you can now just chuck it in your resume. Then we have new external identifier. So now we have for CVEs and the other one is security other. So you can literally now say this is a CVE ID and the security other, this is for, for instance, a GitHub where you have GitHub has its own types of IDs for security vulnerabilities. We now have that out. Then we have the ability to go on deeper and like how you can associate the vulnerability with package, but how that works. As I said, we have assessments. So the usual suspects are the new ones or EPSS. I don't know how much people are familiar with the security work, but EPSS is one of those ones where you can indicate like how much it's likely the likelihood of being exploited, but also facts. So facts will go on later. This is a way how you can communicate like, yes, I have this open source component. Yes, we know there's a vulnerability before the threat, but actually we have made a reconfigured this component that you can actually not exploit this vulnerability because simply we reconfigured it so it's basically behind our firewall. So it's not, it's in real. So yeah, let me just quickly again, Rose already gave a quick intro to the profile, but let's make it a little bit more kind of concrete. So you have, again, you have the core profile and then you have the software profile and just be honest, the security profile for the first step we're focusing on is security information for software, but we designed this back that it can also be extended to hardware. As the hardware profile comes online, we should also be able to cover it. So yeah, we started with a simple, like a simple application. We have some dependencies and now we can do, yep, let me go next. We can add some extra bits to it. So now you see the visual, the security profile. So now we can add the CVEs. So for people not familiar with CVEs, it's kind of the standard way from the, to indicate like what an identifier for a vulnerability. But as said, you can also do it for things that do not have a CVE. So if you have your, in your company, your own security database where you assign your own identifiers to vulnerabilities before a CVE is filed or maybe it's only used internally and then you can now do that. You can assign your own identifiers and you will be able to do that. So how does this kind of work? Well, so basically you will have a software artifact and a software artifact that can be a package, it can be a file, it can even be a snippet. So you can even say like this snippet has a vulnerability that you can really point to it. And then you basically can say has an associated vulnerability and then we have a new element that we introduce for a vulnerability. And similar wise, you can also say like, hey, I have a vulnerability and actually I have an assessment. So the vulnerability itself contains relatively few information because we build things around it. So what do we call assessments? So for instance, you can say, okay, I have a CVS V2 score for this assessment. I have an EPSS rating for this assessment. Or I can say like, oh, it's in, I know it's in known exploit catalog. So all of these is what we call assessments. These are kind of like opinions about this vulnerability that different people have. So it's also possible, for instance, that Rose and I, we differ about the likelihood of expectation or the risk assessment from this vulnerability. So that's not also possible. It's not just one number. You can have different people expressing different views. So you can maybe say like, oh, from my security tool provider, this thing has a critical, but after we reviewed it the way how we use it, it's actually no longer critical, it's actually a medium. And so you can now nicely encode that in the new spec. So this is kind of how it, how the assessment look like. There is like the relationship. So again, here we have the CV and then we have the assessment. And it said, now we can point out it's actually a too many relationship. And it's kind of like a little bit complicated because there's multiple things. So we have the vulnerability. We have the product. And then we have the dependency like the open source tendency likely that's inside of this product. So it's actually, it's a triple relationship basically that you have. It's not normally a known SPX. We had like usually like a 1.1 relationship. This is actually a triple relationship because we say like, hey, we have a vulnerability, we have a product and then we have something in the product that is actual vulnerable. That's how we basically make the assessment on. So that's why it's maybe a little bit complicated. And you can also now do effects. As I said, effects is a way where you can say like, hey, what is the, how do we think this vulnerability was the impact on it? And so you now can basically like, yeah, I have a vulnerability. And I say like, oh, I'm investigating whether this vulnerability has an actual impact on my package. But there are more, as I said, effects. How many people in the room just like Shove and how familiar with the effects? A few, but not all. So basically you can in effects, it's what are actually multiple effects standards. So a little bit complicated, but there are three with SQDX, technically it will be four. But basically the way how we implemented effects in SQDX, it's basically, it's compatible with all of the other effects. We basically maintain the core information. So you can really say like, hey, I first send out the first information and say like, how I'm investigating. Then you can say like, oh, hang on, we've investigated, I'm gonna amend it. To basically like, oh, I have a new thing. So it's like, yes, actually affects myself. So you can do basically update your relationships over time as it goes internally to your security process to basically figure out like, what is the impact of it? So this allows you to directly communicate, for instance, with all of your customers from like, yes, we're doing this. And so this has a lot of benefits for us now I know that some companies this communication now goes over email. The view is to basically make this digital and then you can basically the same point where maybe you have a REST API where you distribute your S-bombs and then your customers, if there's a big, say, new log4j, they can just go to the REST API and they can also get all of the Vax information. So instead of each customer having to go to your dedicated website for log4j, the idea is we can make this all machine readable and you can nicely communicate this in a digital format instead of having all of your account managers communicate to all of the customers like, no, no, yes, no. And yeah, let's do things digitally instead of things manual. For us, we always are looking for your feedback. As I said, security is not easy. There are always things that we case them on. We're now basically really working on modeling real world cases and then trying to model out like, how does this work? How does this look like? We did make some omissions just for the first 3.0 to keep things simpler and that we passed on to 3.1. So we haven't modeled everything. We do know that we are, we think we can model them in 3.1. It's just basically we had that some point out of a cutoff point. Basically, this is 3.0. This is 3.1. So yeah, you can join our meetings. Our meetings are every Wednesday for the Europeans is at 8 p.m. For Gary, you know the US times. All the translation is like 10. 11 a.m. 11 a.m. West Coast. And so you can also submit issues to our security model. So I should now be nice within my 10 minutes.