Name: Unlocking Transparency Compliance: The Role of SBOMs in Modern Software Development
Uploaded: 2025-02-25T07:08:05.121Z
Duration: 52 min 4 s
Description: Unlocking Transparency Compliance: The Role of SBOMs in Modern Software Development

Transcript for "Unlocking Transparency Compliance: The Role of SBOMs in Modern Software Development": Unlocking compliance, the role of SBOMs in modern software development. Joining us today is Patrick Beckman Lapré, digital trust specialist at DigiCert, and Dave Roche, director of software trust at DigiCert. Before we start, we'll wait a few minutes to allow, few more delegates to start, and then I'll take you through some housekeeping items. Okay. It looks like we're getting a full house. So the housekeeping items, today's webinar will be recorded and will be sent out after the webinar ends. Throughout the webinar, you can ask questions using the q and a feature and chat function within the platform. There will be a q and a session at the end of the presentation. And if we don't get to your questions during the webinar, we'll reach out to you afterwards to ensure that we provide answers. And finally, if you are experiencing any technical issues, please check your Internet connection and try refreshing your browser. If the technical issues persist, please send us a message in the chat, and we will help you. Thank you once again for joining us. I will now hand over to our speakers, Patrick and Dave. Thank you, Serena. Yeah. So hi, everybody. I'll introduce myself first. My name is, Dave Roche. My mom calls me David usually though when I'm in trouble. So you guys can call me either depending on which way, you feel about me. I've been with DigiCert since, 2011, and I've been working as a product manager since 2015 on our software trust solutions. It's, very much, focused around ensuring that your software is high quality and has a verifiable digital signature to allow it to be, transmitted, to customers and devices with irrefutable trust. I'm based out of Ireland, so working to, in the European, area, but travel globally to meet customers and, talk about our services. Now over to you, Patrick. Thanks, Steve. Welcome, everyone. As stated, my name is Patrick. I am based in The Netherlands, and I'm already working for almost two decades for a entity that was called DigiCert before. And after the acquisition by DigiCert, I became a member of the, group that is called Digital Trust Specialist. And I have a special focus on content trust from the first place. But also very interested in, everything which is related to compliance and regulations because we all know, especially in Europe, we, love to regulate everything we are doing. And that means that I have also a depth knowledge of everything that is coming to us and where we need to be as a qualified trust service provider as we are in in Europe. That brings me to the, the bridge on, the next slide that says, more or less, every company is a software company. And let me try to explain what I mean there. In our digital life today, we are depending on, digital transactions everywhere. Whether it's booking a flight, whether it's doing a bank transactions, whether we are heating our homes using a smart metering and smart devices in our home. Today's life, we cannot do without any digital transactions or digital, working spaces there. So that depends that we are leaning on everything that is happening there. And that also means that things need to be regulated or need to be standardized. Because if we don't have, standardization or re regulations in place, what are we going to do? How are we going to communicate? And how do we know that it is secure? And that means that we see in a lot of areas a lot of regulations. And those regulations are, more or less global. We see a lot of regulations in Americas. We see a lot of regulations in in the European area, but also in APJ. So more and more, we see a global approach on every regulation. And That's it. And you you you were saying that in in Europe, we're we're heavily regulated, but, I mean, The USA is giving us a good run for our money. Look at all that in Asia. Right? It's, maybe our reputation precedes us. Yeah. And and that's what you what you see in this slide. Regulations are everywhere. Over all over the world, we see regulations coming to us, and and what does that mean? And, today, we will have, let's say, a little bit specific focus on on new requirements that are coming up. And especially if you look in Europe, we look at NIS2 and DORA, for this case. But it is applicable, as you said, Dave, in in all areas. And if you look at the regulations and directives that become applicable, what does that mean? What does that mean for for people? What does that mean for organizations? But also, what does it mean for us as a, let's say, as a company in the cybersecurity space? And which regulations do we are applicable for us or for companies that we, provide our services to? But in the meantime, if you look at all those regulations, it is about, controlling, knowing what you are controlling. And if you look at it, what we see, especially also in in the software space, is about transparency. We need to inform our customers, but also be sell, be aware ourselves. What are we providing to the market? How are we doing it? How are can we control those those assets? So that means also that if you look at different areas, and there is, this nice slide that you see here, what you will see, and this is something that Gartner has been, analyzing, in back in 2022, software developers were creating software based on only functionality. That was the normal way we did it. With all the new regulations that come into effect, or some of them are already in effect, there is a different approach on how we deal with software development. Software development is, let's say, becoming in a new phase of the of where they are. And, Dave, can you tell us a little bit on what you see there? Yeah. Absolutely. I think what's what's really standing out to me here is that, the industry and government has had to, roll up their sleeves and get involved to, to really kind of force organizations to bring about better software. And and, of course, the benefit of that is really towards their their customers, their their end users of their products because, you know, quite frankly, the organizations were not necessarily doing, what was best. And software was getting released, and there was dependencies that in there that were causing vulnerabilities and risks. And, and therefore, I don't think this is overreach. I think this is, this is very appropriate. And, as you said, Patrick, some of these are already live today. And even though we're in the EU, one of the ones that stood out for me was the, the FDA, the Food and Drug Administration. Right? If you want to sell, products in, even in Europe, you have to adhere to their pre and post submission, for health care and medical devices. And and that requires, like it says here, the distribution of s poms, to bring transparency to what that software is made of. So, yeah, we'll dig a little deeper into it. But, yeah, it's, it's here. And, it On the January 17, their door became, let's say, effective. So all our financial industry companies need to, at least to be aware of it and and hopefully are already complying to it. Yes. If you look at the, transparency that we spoke about a little bit before, because we all know, we need to make bring more transparency to the market. We need to make sure that we know what we are using. And, if you look at the whole software development supply chain, one of the topics that is in there is the so called software bill of materials. And can you tell us a little bit more about what the benefit is of using the those s bumps within your software development, tooling creation, etcetera? Yeah. Yeah. So so, like, I think what SBOMs do is they bring, they bring, visibility to what the software is made of. Right? And, I think, you know, developers are borrowers. Right? They they for for years, they have been, not reinventing the wheel on things that that that they don't need to do. Simple basic development functions like logging, authentication, things like that. Right? They take a library that works, they build that into their service, but they they're customizing and working on the innovative part of their solutions. So so developers are really focusing on on differentiating the software from their competitors. That's their that's their role, is to make the software function in the specific way that the organization requires us. But that all that all means that rather than reinventing logging or reinventing authentication or or encryption, you pull in these widely known libraries, and get those to to function as a a standalone piece of your software. So being able to tell your customers and your partners and regulators that these these are the libraries that we depend on and these are the versions that we are using, makes the whole process more transparent. Right? And and how does that work in terms of this supply chain? Well, again, from a supply chain perspective, what we're seeing here is developers writing code gets built, gets packaged up, third party libraries and dependencies get pulled in and recycled, and eventually goes out to the customers. And that could be to a a a website, it could be into an app store, It could be pushed on to a consumer device or a health care medical device in a hospital. So what we need to be kind of focused in on here is is, you know, where can we ensure, that we're doing best practice approach to keeping that software safe? Right? And at the writing code level, what we need to be doing is making sure that developers who are who are committing software to their git repo are signing those commits. That means that I am committing my name and my details to that to make sure that it's coming from me and that somebody can't impersonate me, write code, and introduce some vulnerability into the into the git, which, is not going to bring any kind of good outcome to it. But also practices around making sure that when I do that, that there's checks and balances. So software composition analysis is a well practiced discipline. Organizations have really, you know, started to ramp up their adoption of this. And what that does is it just looks at the source code. Right? It looks at the source code whether it's at every time a developer commits or it's a daily function or maybe multiple times a day depending on the cadence. It looks to see what are what what third party, dependencies have been introduced and what they are. And it gives a report back to say, well, you may have a good library here, but there's a vulnerability with that. You should go upgrade it from version one dot four to two dot three. Okay? And so that's the best practice there on writing code. In terms of building, making sure that you're you're managing the keys and the certificates that you're going to use in the signing process, the life cycle of those. We have quantum computing on the horizon, making sure that, you are preparing for that. But also, in terms of just general key strengths, key security that you have within compliance store devices that they're not vulnerable to theft if somebody did break into your bill server. And the the process of reproducible build. So making sure that you build the same thing on different build servers a couple or two or three times, that the outcome is the same. That tells you whether or not the build server or the process around it is compromised because it's all well and good saying my source code is good. When you inject something during the build process, your software is is is going to be vulnerable because of that supply chain type emotion. From the packaging perspective, making sure you you digitally sign your software, before you distribute it. You generate, a software bill of materials as well at that packaging level. You can also apply a digital signature to that to make sure it's not tampered with. It's a JSON file in format. You don't want it to be altered by somebody as well. So, digitally sign that, and that therefore makes that irrefutable as well. There's also this this theory of of binary analysis. So not just looking at the source code earlier in the supply chain, but but what did you build? Right? Did anything get introduced? So reverse engineering that, checking into and comparing what what was in the source code to what ended up in the package to see if anything was introduced that was unexpected. And then from the third party code perspective, just keeping on top of what your dependencies are. Right? Managing those, keeping, curating a list of what you are using, what versions they are, and being able to, have insights to if something changes, that that will that will trigger, a new release version of your software to be, implemented and you pull the developer back in. And and therefore, you're going through that life cycle process of improving your software consistently, without, it being a kind of a reactive approach. Right? Developers are very good at being proactive around features on roadmaps. We also need to get good at being proactive around dependency management. Yeah. And and do you also see, let's say, more or less the the the creation of SBOM, but also the the the threats scanning or the threat scanning, should be done in a, let's say, in a repetitive way? So at the moment you create it, you roll it out, you still need to make sure that you are scanning the software because it could be that the vulnerability, of the next phase will be in there and you should replace it. So it is a continuous way of of doing your supply chain. Absolutely. And and, look, we'll we'll talk about it a little bit more in detail later, but automation is the friend of an organization here. Right? So all of these things we're talking about can be implemented as part of an automated, CICD process. And whether that's the SBOM generation, the signing, the scanning, what whatever those disciplines are, they they can be automated. Now not everybody is is that at that level of maturity to be able to do that and be able to do that multiple times a day. But it it's it's it's a journey that everybody's moving towards. And and, again, it won't be one size fits all for every organization, so don't be trying to adhere to something that doesn't suit your business. I would just advocate that find what works for you, automate the parts that can. The more you can, I think, the better it will be? Removes human error, makes things easier for, developers and and security too. Because if you're automating, you know they're happening. And, therefore, that's a good thing. Great. You you mentioned the, especially the security, the tooling, the monitoring that that developers now need to build in. That also means that, let's say, the complexity of your, software development chain goes up. And we also see a lot of, let's say, teams working in different regions. And how are we looking at the scalability of those complex global teams that are happening today? Yeah. And look, I think every organization, DigiCert included, has developer teams all over the world, working on different product lines of business at different levels of maturity. And, we've got some products that we have been, running in the in the business for over a decade. We have new products that we only launched in, actually, we only launched one or two in in in December. Right? So we there's various products at various levels of maturity and because of that, you're gonna have, different, coding languages in use. You have different CICD tools or, capabilities. You'll have different release cycles, and how those are released. Some of them will have adopted an agile process. Others will still be in a in a more, planned, way. Others will have full automation, and it'll be for different, formats of of software. Some will be developed and be pushed into app stores. Others are for, consumer devices, desktop software, server software. So, like, this is a a reflection of a of a of an organization, of every organization, really, because you have multiple pieces of software at different stages using different tools. What what we wanna take away from this is that regardless of, you know, your coding language or your CICD tool or or or the the maturity of your software is that the practice around keeping that software safe is still universal. Right? You still need to be able to analyze what's in the software. You still need to be able to sign it. You still need be need, as per the regulations, to be able to monitor it, to update it, reduce the meantime to repair, be able to distribute software bills and materials. That's consistent. The regulations don't care how you do it, how old the product is, or anything like that. They're just saying, you you do this now for every line of business. So, in that regard, you know, organizations may need to have some kind of flexible controls to be able to wrap around these different, characteristic, products and software that are that are making the money for their business today. So going back to to what you're saying, independent of what you what you are using, what is, let's say, what you did historically, the message should be all code needs transparency. Yeah. I mean, absolutely. So regardless of whether this is a code that's, you know, five or more years old, that's what we kinda call legacy, whether you're implementing libraries which are coming in from open source, whether you're using third party dependencies or license code that you're working with, partners. Mergers and acquisitions is actually very interesting one and one that we come across when we talk to customers all the time because there's a lot of consolidation going on out there with with organizations. And when when when that happens, products come into portfolios, developer teams come over. There isn't a need necessarily to to start telling the the the the the the organization that's merged in which you that we have to do it the the Digicert way or we have to do it a particular way. What really is important is about getting all of the checks and balances in place. Right? Making sure that everything is done. You don't have to get them to change their CICD. You don't have to get them to change their coding language or anything like that. You know, that what's most important is is to just make sure you're you have control around what's in that software that they're able to, make it transparent, that they're able to digitally sign it, that they're able to, be able to react and respond proactively and reduce mean time to repair so that, yeah, if there is a vulnerability introduced, because the researcher detected it after you've released the software, Then you go and you you you go back and resolve it, then you push a new version to help your customers and and and and then for their therefore not to be vulnerable, by, by you proactively providing that, that fix. So it's it's, yeah, like, regardless of the the the the coding or the the maturity of the software, all of these still require you to be able to provide that that transparency and to be able to operationalize that as well. Great. If if I go back to, let's say, to the regulations, and let's focus in in this regard to to Dora or to NIS2 Directive, especially in in, in the European region. Let's say, just creating an SBOM and do all the things that you just explained to us, there there is, of course, more to be done before you are are, let's say, compliant to those rules and regulations. And, also, what you see there is that the objectives or then goals of those regulations may differ. So it's let's say there is an overlap, of course, but let's say specific DORA related topics on third party risk management versus cybersecurity risk, on the NIST, NIS2 Directive there is different. How do you see those kind of regulations fit in there? Yeah. And and I I think they're trying to solve some kinda universal good good practices. Right? So it's about making sure your software is verifiable. Right? That you, that you can you can your software can be identified. Right? If it was you producing a Patrick that when I received it, I know it came from Patrick. Right? I can I can do that? The other thing is about making this, part of your operation. Right? So that it's it's it's like, good housekeeping going forward. Right? It's that you're you're tracking all of this stuff, you're monitoring it, you're putting the checks and balances in place, so that so that your the quality of the software is is is is as high as it can be. Right? And then the the final thing is around, adhering to, kind of that guidance so that your your customers can trust us. Right? Like, being able to distribute stuff to them, to to so that they can see what's in your software will help them, you know, gain that trust and and and retain that trust of you as an organization. And yeah. So and so, like, this slide is a is a nice one to to start with because it talks about that that verification. Correct. So you must be able to verify what's what you are using, let's say, at any time, any place, anywhere. Right. Absolutely. And and and, you know, how how do you do that? Right? So this is this is broken down nicely in this slide here. So, we've got a couple of ways of analyzing the software. Right? Your your software composition or SCA as it's it's, labeled here. That's about looking at the source code. Right? That's going to be able to, detect from the the code level what libraries are being pulled in, third party, open source ones, and be able to make an inventory of those. The the binary scans to come at it from a different perspective, but the outcome is generally the same. That's where after you've turned all that source code into a binary, that it reverse engineers that and sees what's inside it. So it's, it's two approaches to the same thing and actually, it's good, a very good practice to do both because you have a kind of a belt and and suspenders type approach where if you don't catch it early in the software composition, you'll catch it in the binary, scan. And often what we say is the software composition analysis is like your continuous assessment if you're in a student in university, whereas the binary scan is the final exam at the end of the year to make sure. You know, you're checking before the software goes out the door whether or not it's, it's worthy of, your organization. The other thing is about validating the releases. Right? Just making sure that during the release process that you're doing all of these things, because, of course, software releases become something that have a regular cadence. Sometimes, you know, very mature organizations with with, high degree of automation are releasing multiple times a day. Other times, it might be more of an agile weekly, biweekly type cycle, and sometimes organizations are just making small updates, a couple of times a year. So, you know, just just making sure that as part of the the automated build process that you're validating those releases. In terms of build integrity then, this is about making sure that there's robustness in your process, that you're able to compare and contrast. And and if possible, as a best practice, build the product multiple times, compare the outputs, make sure that there's no issues with regards to the the build process, the build servers, and all of those, internal, mechanisms and and toolings that you use to turn your source code into, a piece of software. And the the other thing then about, verification, of course, is, you know, the s bombs themselves, they bring that transparency. They help your customers verify whether your software is good or not. And assign those. Right? Apply a digital signature to them so that, you have the the ability to let your customers know that this software is, what it's made up, but it it's that you've also been able to, to be able to ensure that that evidence is not being tampered with. Right? That your your customers can trust the s one that they've that you've shared with them and that nobody has made any changes to it, since it's been, provided. So, again, the knowledge of what's in the software then is irrefutable. Great. But so that also means that if you, if you create those s bumps and you deliver them to the customer, the customer needs to do also or could do something with it. And that brings me more or less, to to the next slide. If I have that bill of material, in there, how does it help me? And let's switch to the next slide in there. To hey. What do I need to do with it? It's nice that I have a list of, let's call it, ingredients in my software package that it's signed, that I know it's coming from from Digicert or from some other, software vendor. But then I need to do something with it because taking that as it is doesn't help me. Right. Right. And and this this is really the power of s bombs that and it's the part that doesn't get spoken about almost, at all. And this is the ability to operationalize your s bombs. And and it it's not actually just for the customer. Right? Because great for the customer if they can build an inventory of all the software they're using from the vendors, keep track of those dependencies, then they know, if there's another log for j, they have the ability to say, well, which of our softwares, has a dependency on the log for j library? And they'd be able to understand, okay, there's a software component from Digicert. There's one here that we use from, Google, and there's one here that we use from Apple. So we need to understand whether those Log four j versions are are are vulnerable to this latest, this latest risk. It's it's it's equally, if not more important, for an for the organization who's producing the software to keep track of of the dependencies they are are are using in the software that they're shipping. Right? So, again, if you operationalize that, you have the the opportunity to proactively, fix software, get new versions out there to your customers before they start telling you that, hey, there's a there's an issue with this dependency in here. Right? Nobody likes, again, from a product management perspective, if a customer comes and tells me there's an issue, that's the worst feeling in the world. Finding it and doing that as part of the development process, fixing it before customers, even get a chance to to notice that it's there, that's that's, you know, that's the best practice that we all are striving for. So operationalizing internally, is really something that, we think helps. And and, you know, DORA and this too, the FDA, all of these regulations, they all talk about reducing mean time to repair. Right? And that is the the the the the the process of getting the next version of the software out there once you know that there's some issue with it. However small it is, right, whether it's critical or or high severity or or or lower, making decision there. Obviously, the critical ones and the high need quicker, resolution times, getting a new version out there to your customers and proactively letting them know. I mean, that's gonna build huge, reputational, goodwill with your customers if they know that this is a priority for you as a business. So in in principle, what you could say if you are using, SBOMs within your company and you act as expected to it, it it drives your security policy internally, externally, but also ensures your trust to your end customers or to your own customers internally. Yeah. Absolutely. And and, and, like, what what that builds up then is this this, muscle memory for doing things better and doing things right. You know, it's it's it's you using your own s bombs to make better decisions. Right? Whether or not, those libraries are worthy, that can as as it says in the in the green pillar here, you know, you get you get then to a level of maturity where you know which versions of, the libraries and and, open source, components that you're dependent on are the ones that we should be using. Right? That you're not using older versions and you keep track of that. Right? Like, we often see software where organizations are keep innovating new capabilities and new features, but the library that they were dependent on for some common service hasn't been updated in eighteen months. Right? Those libraries, are being updated by those open source developer teams. So you need to keep pace with that. Doesn't mean you always have to adapt the newest one, but a good stable version and one that you're keeping track of to make sure that that stable version is not now, become vulnerable because of some something a researcher identified. And one thing here that we're kinda seeing as well is that our customers are asking Digicert when they buy our products. Hey. Can you can you give us the software bill of materials for that, that installer or for that, CLI or for those containers that we're going to deploy into our environment? So customers are asking us. I know that I'm sure customers are asking you. And also, if you're in that, if you're under the the the the remit of any of those regulations and, to a degree we all are now with the with the EU based ones, we have to stay on top of this. And, you may have to provide those to your auditor, you may have to provide those to a regulator, and or you may have to provide them with a to a customer. So, make it part of your practice. Right? Start building them even if you're not asking being asked for them today because, trust me, it's coming. Yeah. It it will be there. We will be confronted, more or less, with it. Not typically mentioned before, but let's say, of course, we hear a lot of things about, tools that you can find on the Internet to to help you with those kind of, pieces in there, whether it's scanning, whether it's creating your your s bomb. Yeah. But in principle, you say it is a, a enterprise approach. You should do more or less all all or nothing. And, at Digicert, we have a so called software trust manager. Can you elaborate a little bit on what's all in there? Yeah. Absolutely. So, we, of course, have a, a solution that is, best practice in terms of applying digital signatures to software throughout the the CICD process. Developers can apply signatures to their software, also, sign the the commits to their, repos. And, as part of our conversations with customers have evolved, beyond looking for signatures and and, and us providing regulated and compliance services to manage signatures, customers have asked us, you know, how how can we ensure that the software that you are signing is is worthy of that? So we've started to introduce, earlier checks in the in the process to do scanning, both at the software composition level, also do binary scanning later so that we offer customers that ability to pick and choose the approach that's more appropriate to them. And, of course, what's now evolved from that is the ability for us to help customers with generating s bonds, signing them. Right? That's our bread and butter. But also managing them. Right? So keeping a a a track of the latest release of your software and all its dependencies. And if we detect that, dependency in your software has become vulnerable since you released this, right, post release, we're then able to proactively notify you, that that's happened. So you so the then you have that alert. You can get it into a Jira. You can get it into a Slack, whatever or both, whatever is whatever is the best way for you to consume it. And then organizations have a proactive alert, system so that they know what to go and resolve and, keep on top of that that that dependency management. And and, of course, then the other thing with regards to all of these compliance is that, you will be often asked to provide evidence that you're adhering to these practices, whether it's signing, whether it's scanning, whether it's dependency tracking. Our solution has auditing of all the signing activity. It records all of the scans and the dependencies that are within those, within that software and the versions. It will help to track releases over time so that you can show, the progress you've made to resolve issues with your software, throughout its life cycle. So we're we're trying to, again, help customer to to solve, some of the challenges towards, the the regulations and, that are out there. Again, government based ones as well as product. Our we're not we're not saying here that the solution makes you compliant because you use it. That's not the advice that we're giving. We're saying that a solution like ours can help you. Again, you have to implement all of these practices. There's there's loads of features within the product. You you but you have to implement and adapt them and make sure that they are working for you against the regulations that you're aligned with. Yeah. More or less. It it is it is a piece of the puzzle, and I see also in the, let's say, in the contractual side of, what is happening that we get more and more questions from, from customers that's that want to have a addendum to the contracts that, let's say, based on what we provide to them, that we are, let's say, taking the regulations, whether it's NIS2 Directive or DORA or otherwise, into account in our businesses. I would like to thank you, Dave, for your comprehensive, setup here. And I would like to hand it over to you, the questions that might be there at this point in time. Serena? Thank you, Patrick and Dave, for the valuable insights that you shared. So, the chat has been very busy. We've got a few questions that have come through. And just before we go to our first question, if we don't get to everyone's question, just a gentle reminder that we will follow-up with you directly. So let me, put our first question on screen. Alright. I'm gonna show. So the first question I'll share in a moment, it says, how are regulations shaping software development? Patrick, I think that's a great question for you to take. Yeah. Thank you. If if you look at, and and we spoke about also during during the webinar, software development is, more and more, need to stick to the rules and regulation. That means that software developers don't only provide functionality, but they also need to build in monitoring, logging, auditing, etcetera, etcetera. So, the way development teams operate, is different from what they used to do in in the past. You now need to make sure that everything that you do is is in there, that it is compliant, that you be transparent on what you are doing. So more and more, you will see that regulations or directives will be, let's say, the starting point in the, development process there. So those regulations needs to be let's say, I won't almost say it must be in the DNA of the developers to think about, oh, what do I need to be, developing? How do I need to do it? How can I make sure that everything is is transparent as we spoke about earlier? So it's not just building a functionality. It's the whole complex area around it as well. Great. Thank you. We've got more questions coming in. So, next question is I'm just gonna put that on the screen. So the next one is, there are lots of SBOM vendors out there. What sets Software Trust managers SBOMs apart? Yeah. I'll have a go with that one, Serena. So, of course, we're we're we're biased here, because we're talking about, software trust manager. But, I think what I would say is that in terms of how we can help customers with, with s bam is that it's not just about generation, it's also about the management perspective. We can generate the s bams in a couple of different ways. We can generate it from the source code analysis, integration, or we can do it at the binary level. So we can do it at at two different points in the supply chain. You can compare and contrast. We can generate it in the formats that that are regulatory compliance. So it's cyclone DX or SPDX you choose. We support both of those. And again, you know, from from not just generation, but also operationalizing them. We can track what's in your response and and help alert you, if if something changes, which is going to introduce a risk for you and your customers. So, you don't get that level of maturity from, a lot of these free tools out there in the market. Again, I think these are great place to start. Right? As as you're learning what it how the nest bomb is and how to generate it. But for me, it's a little bit like, you know, chat GPT as an AI tool. I use that personally, but my organization hasn't signed off on that as being a compliance tool that we use for our AI, support. And so what you use to begin with to learn the process isn't necessarily what your organization is going to be happy with, from a a standard perspective. Great. Thank you. I think we've got time for maybe a couple more questions. So the next question that I'm gonna put through is, what are the potential risks to cosigning certificates in a post quantum world? Patrick, would you like to take that one? Yes. No. No worries. As as probably most of us know, we are currently using RSA or ECC, algorithms, and, let's say, post quantum or quantum algorithms could potentially break those, algorithms. And and that happens because we have outstanding software, in there. So, it could be that you can break into a existing, signed software bill of material or software, a bill there and pretend it is coming from Microsoft, but it comes from a fraudulent person that wants to try to to break in. So, yeah, post quantum will definitely has a has a potential risk in there, because post quantum is not set in stone yet. It still is evolving. So the advice would at least be make sure that you look at it, make sure that you use a, I will call it hybrid technology in your cosigning, and be aware of everything that you already signed based on existing algorithms is kept safe. Okay. Great. I think for our final question that will come in, we it will be what yeah. Hi. So I I see one here from from Chris Christian so that we might answer as well. Okay. Christian's asked a couple. Is it okay if I jump on those? Yeah. Sure. We can definitely do that. Yeah. So Christian's first question was about what USB tokens we use. So, Christian, again, you're you're you're correct there. We we use the the safe nets from Talas as a as a token. We partner with Talas for the provision of tokens to customers. One thing I will say about about tokens is we're seeing them used less and less for key protection in terms of code signing certs. We've introduced a a virtual token, service, which we call key locker. It creates the key in the cloud. It stores it for you, and it gives you the ability to use that without having to carry one of these tokens around with you. And and therefore, you can you can sign compliantly, in the knowledge that the key is available to you wherever you are. And and the very good thing about the virtual key locker service that we use is that it can be integrated with your CICD. These tokens cannot because when you try and integrate it with the CICD, everyday you'll have to put the pin in. So it's a very manual process to use the token. So we're seeing a lot of customers move away with that as they get better at automating their software signing. So that's just one thing, kinda to note there. If you're interested in that, we can talk a little bit more offline around what we bring there. I also see Christian asked a question about our IP six, IP version six, addressing scheme. Patrick and I are not, on the infrastructure side, but we will be sure to get you an answer to that as well offline. We'll we'll connect you in with somebody who's, well versed in that, from the from the Digicert perspective to get you a clear answer. So thanks for raising that. Promise to get you an answer on that too. Great. I think that concludes the q and a session, for today. So thank you everyone for all of your great questions. And any we didn't get around to answering, we will respond to after the webinar. I'll hand back over to Dave to summarize and close out. Thank you very much. Yeah. Thanks very much, Serena and Patrick. I think we had a great chat today. Hopefully, everybody learned something. If there's one thing that I would say about, the regulations is that they're here. Right? You it's not a this is not a problem for tomorrow. It's a problem for today. If anything, it was a problem for yesterday. But, I would say, you know, get up to speed with that. We do have a very nice white paper around our regulations, with with regard to DORA and NIS2 Directive. It applies to software trust manager for software signing, but also certificate life cycle management on our enterprise devices. That's a good place to start if you want to, to read up on that. And and I just say, you know, get into that. Look at it from a a very much proactive perspective. It's about being able to fix problems with your software before your customers come back to you. So it's not a tick box exercise. It's not about generating s bombs and pulling them on a shelf somewhere. This is about software operations. And, it's very much in your best interest to get out there and start, aligning with this stuff before your customers consider moving to other vendors and solution providers that are doing it. So, yeah. Get stuck in, get going. And, again, thanks for tuning in. Thank you, Al. Take care. Have a good day, guys. Even DORA went live right this week. Was it this week? Or