 Okay, well thanks everyone for coming. I'm gonna talk today about security advisory programs and we're gonna talk about security advisory programs, we're talking about communicating vulnerabilities that are in your software to your customers. I think this is really important, especially as we see more focus, more interest on securing the software supply chain and more industry pressure on creating transparency. Advisory programs are a great way that you can work to accomplish this. A little bit of background on myself. I work at BlackBerry and today BlackBerry is a enterprise software vendor selling various security solutions, mobility solutions, as well as embedded components for folks building embedded devices. We've got real-time operating systems, libraries, SDKs, things like that. And I lead the product security programs and operations team. We've got a pretty wide set of responsibilities. I think most relevant to the talk today and to the track here is that I have the open source programs within my team. So those are the folks that are building the open source bill of materials, the full software bill of materials as well as license compliance material. And then I also have the security communications team. So that's a team of a program manager, technical writer and communication specialist and they partner with our technical teams to deliver on our security advisory programs and a special shout out to those folks because they helped me build this presentation. So there's a little bit on goals today. We've been doing security advisories, vulnerability communications for a really long time and we see a growing need here so I really wanted to come and give our tips and tricks, share some of our templates and some of our thought processes around how we do this in hopes that it'll help somebody else get started with their own program or maybe you have a program already and you're looking for different ideas or different ways to augment your program. I come at this from an enterprise software provider perspective but there's nothing here today that is specific to that industry, that vertical if you're working in non-profits delivering software or you're maintaining and delivering open source libraries pretty much everything today should be applicable to you. So there's a couple of big industry forces we see really pushing on the needs for these programs. One of them is that every year we run statistics, we run metrics on our own, our own inquiries, our own data around requests for the impact of vulnerabilities as it relates to our software and there's just more and more customers every single year it keeps going up, 60, 70, 80% increases just incredible demand on both the number of customers asking, the number of vulnerabilities they're interested in and then we also see a really big increase in the depth so not only do we have the scope and the breadth but the depth of what they're asking for. I think that represents a lot of investment into vendor management programs within big enterprises. They're investing a lot into trying to manage that upstream risk and that's where we end up seeing those requests for this data. So the other big force and it's probably not a surprise to anyone participating on this track today, a lot of focus on the supply chain, the complexity of supply chain, the importance of the supply chain and just how diverse and complex the software supply chain is, we're using so much more open source, so many more third party components to ultimately deliver an end product to consumers. Coupled with that, we see a lot of things like for example, the executive order in the US on cybersecurity requiring software bill of materials. That's another aspect of transparency. A lot of what we talk about today is a really good companion to something like a software bill of materials. Think about customers a little more. We service a lot of different customer types all the way from really small, medium sized business all the way to great big enterprise, 10, 20,000 person deployments, big government. This is a little bit of a generalized table, but this is what we see, it may or may not apply to you exactly, but generally, a lot of those smaller and medium sized customers, they really don't have a giant security team who can go and be proactive about every single vulnerability to interpret how it impacts each and every piece of software that they consume. There's much more of a reliance on software vendors to deliver them clear, concise and actionable information that they can use to protect themselves. Not to say that the big enterprise customers don't need that as well, but there's a little bit of a difference there. Those big customers, those big enterprises definitely have a richer security team, probably being a little more proactive because they have the resources to be and doing a lot more of their own investigation, their own interpretation as to how things apply in terms of a risk profile for themselves. The other thing to think about is that the big customers often have longer test cycles. You imagine if you have 10,000 users on a server, you take a bad software update, knocking 10,000 people offline is not fantastic. So we see a lot more of a richer test cycle with these customers, three, four, five, six months. That's a long timeframe and if you're shipping, if you're being transparent, you're shipping vulnerability communications, you're gonna drive churn into their business, you're gonna cost them money and that is of a benefit. We wanna be transparent with them. However, there's much more of an interest there for things like mitigations and work rounds, temporary measures that they can take instead of interrupting their current test cycles. Kind of peeling that back one layer further on the customer front. We see a lot of different questions from a lot of different customers and one of the analogies that we use is, what hat are they wearing? What is the perspective that they're coming at this from what is their background, what's that persona? And high level, again, these are the three buckets we see. We see vendor management, security compliance, which might be the same bucket if depending on which organization you're a part of or engineering, you're seeing architects, analysts, things like that, asking questions around vulnerabilities. On the vendor management side of things, you're definitely seeing kind of higher level questions, kind of clear yes, nos. As you start to veer into security compliance, you're getting more, what's the CVSS score? How does it adhere to your policy? What was your response like? Things like that. And then as you get into the questions from more of the engineering side, you're getting those really in-depth questions, a lot of questions around mitigations work rounds and more context around how the issue could be exploited, the vulnerability could be exploited, so they can interpret that for themselves and how that might apply to their own network. So we've kind of touched on a couple of points already, but why do we do advisories? What is the importance here? I think the most important thing is that we're trying to arm our customers with enough data around the risk so that they can make informed and risk-based decisions as it applies to them and their organization. I think one of the things that often gets forgot about is that that's a great service to your customers. However, it's also a great service to yourself as a software vendor, a software deliverer. If you're aware of an issue, and this applies whether it's vulnerability or something else, but if you're aware of an issue and you don't tell anybody about it, you don't do anything about it, you're holding onto that risk and that liability and you're effectively making a decision on your customer's behalf, and ultimately you may be held accountable for that. By communicating to your customer by being transparent about vulnerabilities in your software, not only are you arming them with actionable intelligence to take whatever measures they need to protect themselves, you're also reducing your own risk, your own liability, and you are performing risk transference. So this is a fantastic win-win situation. So I'm gonna get into a couple of pillars. If you're starting a new program from scratch, these are a couple of things you need to be building towards and thinking about. I think one of the things to keep in mind as you're building a program, generally these programs are executed by the security team. That may look different depending on your organization, but let's assume we're the security team here. We're there as custodians and representatives of our software team and their products. Ultimately, it is their products, but we're there to shield them from a lot of this noise to provide them a service and to take care of these challenges and issues for them. We do need action out of them, we need patches, we need software delivery. But besides that, we really wanna keep all of this noise away from them, let them get back to developing software, building features, delivering value. The other key team that we're there to enable is a customer service and that may look really different depending on who your organization is, how you're formed. It could be a dedicated customer service or sales engineering, technical account management, there's a million flavors. But we're there to enable them to make sure that they have what they need in order to successfully manage customers, to meet their expectations and to make sure they're happy and safe. So as you're starting to build your program, you're starting to form it up, you're starting to gather support. A couple of the key teams, we'd encourage you to talk to and think about. Legal and corporate communications and corp comms might be called public relations or something similar, but legal is, I think legal is really interesting. I think they're probably the best partners out there because at a high level, legal and security have 100% shared goals, right? Reduce risk, reduce liability. We execute upon that differently, we have different ways of implementing that, but at a high level, we're definitely aligned. I think that if you're working with lawyers who have been in the software industry a long time, they'll get this no problem. I think the privacy lawyers are especially interesting. I think there's a lot of shared goals here as well with things like privacy policies and enabling GDPR, building that transparency, building that trust through transparency. Those folks are, I think, really easy to get on the same page with those guys. If you're having trouble eliciting support to go and disclose vulnerabilities publicly about your software, I think you can use a lot of that terminology we just talked about, put it in those legal terms, reduce risk, reduce liability, risk transference, these are all things that should really resonate with this team. Corporate communications is interesting. Their role is generally to control the messaging about your organization, external to your organization, and we're there as well with things like advisory programs where we'll be publicly discussing vulnerabilities in software. These folks have a lot of value to add in helping you learn how to shape messaging. I think there's some challenges. Generally, if you asked every different team in your organization who would like to contribute to editing and reviewing communication, they're all gonna say they want a piece of the action and you're never gonna ship anything, so we really wanna control who actually gets to participate, but we do have some strategies for how you can gather feedback and incorporate that feedback, but at the same time be able to run agilely, so we'll look at that in just a couple of slides. You know, another pillar you really need, as part of building a new program, you're gonna want a coordinated vulnerability disclosure policy. Generally, this is a document that's publicly posted, whether it's on your website or wherever you're hosting your software, wherever's appropriate for your organization. You know, this is a public document that describes your commitment to be willing to receive vulnerability reports from third parties in good faith and to work with them to fix the issues, really software fixes and to enable them if they wish to disclose that issue publicly. It's a document that essentially says, hey, I'm a mature software vendor, and I'm here to partner with you. So great for enabling relationships with third-party researchers who are looking at your product or software, and really great for your customers. It's a really good show of maturity that you have as a software vendor. Okay, so I'm gonna go over a couple of different types of vulnerability communications advisories that we would do. These are, again, high-level generalized. You can slice and dice these different ways. They might have different names of different companies, but this is approximately what you'll see in industry. We have coordinated disclosure advisories and we just talked about the policy. So this is a situation where somebody outside of your company has found a vulnerability in your software and they've reported it to you and there's some expectation that they're going to publicly disclose that issue. They might do it through issuing a blog post, writing a white paper. They might come and give a conference presentation about it, but they're looking to go public and to talk about their research. And we're gonna enable them, but we wanna coordinate with them. So I think one of the worst things you could possibly do is to not have a companion document publicly posted alongside someone else who is publicly posting about your vulnerabilities in your software. If you're not issuing a coordinated disclosure advisory, you could very quickly lose control of the messaging around a vulnerability in your software. And once you lose control, it's pretty hard to get it back. And if you don't take control of it, somebody else will. So we publicly post these. We acknowledge the issue. We provide data on how customers can protect themselves, how they can fix the issue. And then we also thank the person that we've been working with to go through this process. And we'll look at a template of this in a minute. We also have our security maintenance advisories and you could think of these like security patch notes, security release notes. And these are a little bit more simplified and I would think of them as a mass disclosure. We're gonna do many issues. So you imagine as part of your software development lifecycle, you're going to update your open source. You're gonna take, maybe you have a big release coming out for your software and you update a whole bunch of libraries and you pick up 50 vulnerability fixes, 50 security fixes. It doesn't add a ton of value to do a big long, descriptive advisory on each and every one of those, but it does provide value for you to communicate to your customers that, hey, look, we're fixing all these things. If you take the software update, it's gonna mitigate risk. We talked a few slides ago, especially large customers may have really long test cycles. If you're shipping a software update and all your software update says is, hey, we've got these new features and your customer say, well, I don't need those new features, I'm happy where I'm at. I'm gonna ignore this because it would be expensive for me to take this and test it. Meanwhile, there's 50 vulnerability fixes and if they knew about them, they'd probably be pretty excited to take this update. Or at the very minimum, they're at least informed and they can make a smart risk-based decision. The third bucket, the final bucket, incident advisories, these are just in time. These are, I'm sorry, I'm gonna back up a minute there. So the first two categories, generally we're targeting these for the second Tuesday of the month, patch Tuesday. You really wanna hit that patch Tuesday date. This is when IT teams are staffed and ready to not only monitor for advisories, they know they're coming. They're also staffed to do their patching cycles. If you hit them at 4 p.m. on a Friday with an advisory, it's less than ideal. That's gonna take over time, weekend time. Generally, not something customers are excited about. That being said, we have incident advisories which generally don't go on a patch Tuesday and may come out at 4 p.m. on a Friday. So you really need to balance that. There is a benefit of hitting those patch Tuesdays as much as possible. At the same time, if you have critical information, you don't wanna wait weeks on end to deliver that information to help your customers protect themselves. These are, there's a lot of kind of custom work that goes into these advisories. They're on short notice. The situations are very fluid. You may know that you're affected by something. You may know you're not affected by something. You may have no idea at that point in time. We're gonna look at a template of this in a second. But speaking of templates. Templates is the tool that we use, one of the ways that we can gather our partner teams' feedback in advance of actually having to use one of these. So you imagine you're in one of those incident advisories or just in time. You don't have time to ask 10 different people how they feel about something. I mean, you've gotta go. There is a lot of value in gathering that feedback in advance and templating as much language as you can. You can template things like, what are your standard fields? What are the standard data that you're gonna collect and distribute depending on the type? How do you reference your organization? How do you, what are the names of your products? What are the actual names? Not your internal names, not your nicknames, not your shorthand, your abbreviations. What is the actual customer-facing name? You can use templates to do things like help enforce your business rules. Where did follow-up questions go? How can I use this information? Who's accountable for this, that, or the other? You can do really incredible things by driving feedback into these templates. And then it allows you to move quickly as you need to actually use them. Okay, so, I've got a few key data fields here on the screen. There's a lot more than this. We tried to simplify it for the sake of the slide here. You're not gonna use all of these pieces of data in each and every type of advisor you do. Generally, you're gonna cite a CVE regardless of type and you're gonna want to cite the score. So the CVSS score, the criticality, is it critical, severe, or maybe not so much? If you're working on one of those coordinated advisories, you're gonna want to cite the person that you've been working with that found it, assuming they're okay with that. But if you're doing something like those maintenance advisories where your mask is closing, I mean, it doesn't really provide value to go and figure out who somebody else worked with. That should have been covered in the upstream advisory. You know, really critically, impacted software, fixed software, which software is impacted, which software is not impacted, which software fixes the impacted software. Okay, so we've got a couple of examples of our templates that we use. I had to simplify this to try and make it readable on screen. I do have an appendix in the slide deck that's posted to Sketch, so if you want to see a longer template here and a bunch of different examples that we're not gonna cover today, they're all there for reference if anyone needs them. But again, you're seeing some of the common data here that we talked about, right? CV, CVSS, affected or impacted and not impacted, and various other data. So a bit of an eye chart here, a lot of color. We've trained ourselves to use gray to help highlight the data that doesn't change, right? So all of our fields on the left don't change. Some of the various data throughout the template does not change. This helps us really focus on the data that does change and is unique to the situation. And that's what we see in yellow. So yellow is stuff that we have to customize per advisory, per situation. And then we've got a little bit of red in here just for emphasis on really key data. But this is something that we'd post to the website. We go through one of those coordinated disclosure situations with a third party, work with them, and we would post this alongside whatever the documentation is that they would be issuing. We got a little bit different of a flavor of a template here. So the last template was something we would issue to our website. This is something that's a little more hands-on. We have a lot, you know, we've got a pretty complex customer support unit. And we have a lot of actively managed accounts. So a lot of customers who really like that white glove approach, that reach out, that open dialogue, you know, there's ways that you can subscribe to information, but a lot of those customers do prefer the hands-on touch. So one of the things that we do is we issue documentation internally to all of our customer-facing teams and, you know, let them deliver it, however it aligns with their processes. You know, some customer-facing teams will use other tooling to mass deploy this. Some of them will actually reach out, you know, manually through email to their customers and build that relationship. Some of them call their customers. Just a bunch of different way the information gets used and, you know, providing it in this format is helpful to our support teams. But we'll walk through this a little bit. So this is something we would use on, you know, one of those incident bases. It's 4 p.m. on a Friday. Somebody announces a new CV in, you know, a library that we're all using. It's just starting to blow up in the industry. Everyone's talking about it, customers starting to ask. And, you know, we would instantiate this template in a couple of different ways. We might say, listen, like we're aware of the issue, but we don't quite know yet if we're impacted. But hold on, we're gonna figure it out. And we'll get back to you. We may know definitively that we're not impacted and we can make that definitive statement right away. Hey, we're not impacted. It's all good, don't worry. When you're impacted and you know you're impacted, that's where you're getting into a lot more of kind of custom language crafting. That's where we spend a lot of time really finessing the communications. But let's walk through this example a little bit, this template a little bit. And you'll see right at the top here, we'll have a marker for where a verbal and written statement begins. And then in the middle of the page, we're gonna see verbal and written statement ends. This is a cut and pasteable chunk of text that those teams can use. However they use them in their own processes, we leave that to them. We just make the information available. Let's walk through it a little bit. So, company is aware that on this date, details were released about a CV. Generally you're gonna have a CV number, you might have a name at the time. Maybe it's just a URL, but something to reference some primary key there. And then who's reporting it? Is it being widely reported in industry? Is it a specific blog post? Whatever context you can give there is helpful. And then we move on to the meat and potatoes. What's the actual issue? And it's so dynamic, depending on what the vulnerability is, what's going on, is it being exploited, is it not being exploited? This is where you spend a lot of your time filling in these templates. It is really important to let your customers know. If you know they're under attack, you should let them know. There's a heightened risk, otherwise it is very reassuring to let them know. You're not aware, you're not aware of any attacks that are targeting your customers. So, past the verbal and written statement ending marker, you'll see we've frequently asked questions. Generally what we do is we take our written statements, we write up a nice chunk of text, it's tons of context, lots of depth, a really useful piece of communication for a customer. And then we take that and we slice it and we dice it. And we trim it down to really clear, crisp, yes, no. Is the software affected? Yes, no. If yes, what fixes it? How do you mitigate it? You have all those different customer types, all those different ways that customers are serviced. Even though it's effectively the same information, a lot of different people digest information in different ways. And we find this just really helps enable that kind of gamut of different customers. And also the different relationships in different ways that customers are managed, whether that's through automated tools, through verbal conversation, through written email or whatever it might be. This is a list of different documents that we use. I'm not gonna go through the table, I just wanted to have it here as a reference. We do have these templates in the appendix for folks to pull if they're of interest. Okay, so a couple of tips and tricks as you're standing up your program, you're starting to write communications like this. I mentioned before, everybody's using a lot of upstream software, right? That's just a key component of modern software delivery. I wanna encourage everyone to not feel the need to be the expert in somebody else's software if the vulnerability that you need to communicate about is in an upstream library, upstream component, and that vendor, that provider of the software has rich documentation available. Don't be afraid to link to it. You should be the expert of how it impacts your software, but you don't need to be the ultimate expert of the vulnerability in somebody else's library. So link to that information if it's available. Similarly, make sure you identify all of the supported software and the impact of that software. Ideally, you're gonna have either an end-of-life policy that's posted or a software support page that lists what of your software is and is not in support. So if version one, two, and three all in support, you should be accounting for, is V1 impacted, is V2 impacted, is V3 impacted, and if so, what software fixes it? Consistent naming. So we talked before, the templating. As you define those proper names, the proper references for your software, your company, et cetera. Make sure you're being consistent. It's really important that you're using consistent naming advisory to advisory. Your customers will want to take that data and correlate it and run that through their vulnerability management system. So do them a favor, be consistent. And we talked about providing attribution. You're working with the third party directly. Site them if they're okay with that. A couple of things you wanna avoid. Don't make a definitive statement if you are not definitively sure about that statement. There's nothing wrong with not knowing, especially with some of these, you know, these just-in-time vulnerability communications. It's okay to not know. It's okay to say, listen, we know about it, we're investigating and we'll get back to you. And I think that actually provides a ton of value to customers. So if you think of those large enterprises, right, they could have 1,000, maybe 2,000 software vendors who are providing even more software than that to them. And when something like Log4Shell, something like that drops, they're gonna run around to each and every one of their vendors. Hey, are you impacted? And they may or may not get a response by proactively telling them that you're aware and that you're investigating and you will get back to them. They can triage you right to the bottom of their list. They can go move on, they can go and chase down the vendors who haven't communicated, who may not know of the issue. They can go and start working to mitigate the software where the vendors have indicated they are impacted. So even if you might feel like, hey, saying I'm aware but I don't know, that is a big benefit, a big value to customers. That was a really hard one. I think I swear we did 12, 13 revisions or a documentation on that because yeah, it's, hey, we fixed, whoops, that was in the right fix. Sorry, you only know what you know at the time and so long as you're keeping up, right, and you're continuing to keep the information flowing, I mean, that was such a fluid situation, right? I think we were writing and writing and writing and investigating and investigating for weeks, right? And it was the first fix that didn't take, it was the second fix. It was all of the peripheral vulnerabilities that were different things by the same library but customers were so riled up over that component. That felt like the never ending. I lost a few vacation days over that one. I think many of us did. So yeah, I mean, that's tough but right, you, I said before, don't make definitive statements unless you're definitively sure. Honest mistakes happen, right? So there will be times where you make a mistake or you didn't even make a mistake. It's just that is the situation. The industry thought that was the right fix. Everyone took that fix 48 hours later. Crap, right? So you can only do as much as you can but be transparent, right? Keep going, keep updating, keep delivering on the mitigations. Okay, so the templates we looked at before, you can use those manually. You can automate those into your vulnerability management system, script them, you can do all kinds of things. There's some really cool frameworks popping up. Probably a lot of people in this track are aware of things like vulnerability, exploitability exchange, really cool companion to something like software build materials. This essentially lets you implement the security maintenance advisories into a machine readable format and it gives you options to do things like, impacted by a CV and here's the fixed version, impacted but not fixed or not impacted and here's a variety of reasons why. It's pretty cool. There's a bunch of different frameworks that are implementing VEX documents like the common security advisory framework. I know there's other frameworks out there. I'm pretty excited about the CSAF. Not only can you implement VEX in it, it also has other, I think there are four or five other types of documents that you can capture within a CSAF framework and effectively CSAF will let you implement everything we looked at today and more. Starting to wrap up here. I really do believe in the advisory programs. You've done them for a long time. I love working within the program and I think that as we start to see more of that pressure on the very complex software supply chain as we have more people building advisory programs upstream that really puts pressure down the supply chain and it's gonna help everyone be able to resource and to put more emphasis on patching and for everyone that's disclosing upstream that's another person downstream who then needs to patch and disclose so the next person downstream can patch and disclose and ultimately we're gonna push each other to be in a better security posture and just to be more secure as an industry so I think that's fantastic. I would also really like if more people who ran these kind of programs came and gave presentations about what they're doing there's not a lot of content of this type in the industry and if anyone else is doing something like this I would love to learn from you but that's it for me. I think there's just a huge demand for this kind of data. I think everyone's gonna need a program like this as the industry moves on and I really do think that programs like this are our win-win both for say someone like myself as a software provider and the customers who receive them. It's just a fantastic program to have so that's it for me. I'll take any other questions if they're... Yeah, go ahead. That's an interesting question. Okay, so the question was, CV is our lagging indicator so a vulnerability may appear before it's assigned a CV and how can you start acting on that beforehand? I think we do that pretty often. I think you don't necessarily need a CV to start communicating about it but it provides a lot of value because it gets very confusing if you have customers coming through your door saying I gotta know about that cross-site scripting issue like which one, right? It just gets muddy really quickly but sometimes you don't have it, right? Sometimes you have a link to a blog post or some other IOC. I think maybe the solution there is that we have an easier way to assign CVs so one of the cool things that MITRE is doing is they're really pushing for... A lot of things were form-based before. You go and manually request a block of CV so this probably shouldn't get into the details of the CNA program but you can become a CNA which is a signer of CVs for a certain scope. So for us, my team handles the MITRE management and we have a scope of BlackBerry and we assign the CVs for BlackBerry and et cetera, et cetera. Microsoft does Adobe, et cetera. And a lot of that has been through forms. You go to a manual form, you say, hey, give me 50 CVs for the year. When you need to assign one, you go back to a different form, you say, hey, can you upload this data? Manual, manual, manual. They are really moving towards their API. There are some really cool open source tools called a Vologram, puts a nice front end on that which is making CV assignment much less painful, much quicker. So one of my challenges with advisory when we're doing it manually is that we wanna publish our advisory on a certain date at a certain time. Might have to wait two weeks for that to actually get published and propagate it to the NIST NVD. So that's really gonna help, right? We're gonna cut down a lot of that early lag time. I think there's probably other opportunities as well to make it more easier for folks who are not a CNA to assign, right? Because there's a lot of setup there to get yourself to the position of being able to assign a CV. And if you're just doing it for the first time or you don't know what to do or it can be really scary. There's a lot of opportunity for education. There's a lot of opportunity for education on what should get a CV and what does not require a CV. I don't think there's canonical use cases for that at this point, so. Yeah, so we have a dedicated team for that. We have our P-SER team, product security, and SIR response. And they perform really detailed oriented work to figure out that impact, right? So we have kind of two streams. We have, let's be proactive about it, but I mean, there's a lot of volume and sometimes customer questions beat you to the punch, right? And so sometimes you'll trigger an investigation off a customer question. But you go in to figure it out, right? You go in to figure it out. Do you actually, and so the scanners are tricky, right? Because they say, listen, you're using OpenSSL. We see it. But the real answer might be, yeah, but we used like three files. We trimmed it down. We took out that sub-component where we configured something off by default or there's all kinds of things or other mitigations in your product. Oh, this is a critical issue. Well, no, it's not because we did X, Y, and Z to our product. So we have a dedicated function, dedicated process tools. Kind of got the full suite there. So that is a way. It is tough because there are customers out there who say, well, I don't care. I need it to go away. I'm vendor management. And so long as there's a red X on that report from the scanner, I'm upset with you and we need to remediate that. That's a tough one. That gets to more of like a business requirement negotiation, right? The security team can give their input and say, listen, it's not a critical. It's a low and here's the justification. And at that point I would hand it off to the business because that's a business decision, not a risk-based decision at that point. Any other questions? So, I mean, kind of outside the scope of advisory, but so as an example, another one of the programs we run is called Pen Testing Coordination Office. We've got a lot in terms of customer requirements for external validation. So you could have fully staffed proactive, research, SAS, SAS testing, composition analysis. You could do all the things. Check all the boxes and you still get a lot of customers come and say, well, that's good, but I want an auditor to come in and poke at your products, right? So again, that's more business than technical security risk, but it is a big problem, right? And there's standards as regulations pushing for more of that kind of independent audit. But ultimately, I look at that as more of a business requirement and challenge, but yeah, a lot of times you're gonna need to do that. Probably depends on your customer base and depends on the type of products you sell. I definitely see more of a demand there in terms of security software than other types of software or cloud-based software as well, right? Where you're hosting data for the customer. A lot of concern over that. They want more assurance. Any other questions? Okay, thank you so much for coming.