Name: The 9-Day CRA action plan for codebase readiness
Uploaded: 2026-09-02T15:16:12.863Z
Duration: 58 min 44 s
Description: The 9-Day CRA action plan for codebase readiness

Transcript for "The 9-Day CRA action plan for codebase readiness": Where is it being used? How is it being used? Is it being exposed to our users? Is it being exposed to the Internet? You're gonna need to do all of these things in order to do both a proper remediation internally and to the point of your obligations in eleven days, you're going to have to in nine days, sorry, you're going to have to tell the European Union that you know all these things and you're going to have to tell them with high confidence that you know exactly how exposed you are, what versions are exposed, you know, are is this affecting only your users on the oldest versions, your users on all versions? So, yeah, this is, again, this is one of these things that I think we all say we can do. But when when push comes to shove, when we actually have to report a vulnerability, are you confident and certain that you can do all these things, that you can understand exactly where it is? Why don't we go to the next slide? So what tools do you need to to do this? Right? There's a lot of different ones. I've already talked about inventorying. That comes up here. Some of you may be familiar with the term with SBOMs, software bills and materials. SBOMs are one are a great example for us in when we're discussing the CRA because it is explicitly required in 2027 that you have an SBOM for your products. It is implicitly required in nine days that you have an SBOM for your products because you can't do the mapping that's required for a prod proper vulnerability requirement without having an s bomb. Otherwise, you're sort of flying blind. Right? You don't know what's in there, and so you can't do that mapping. So strictly speaking, not required until 2027. But realistically, if you're doing a good job of managing your security, you need to know that now. Similarly, a lot of this other stuff, You need vulnerability databases. You need to know if I've got a thousand pieces of software, of open source software incorporated into my product, what are you doing to monitor those thousand pieces of software? That means you need a vulnerability database. You need exploit intelligent feeds. You need telemetry understanding to help you understand what's going on here. All these things mostly not strictly required until 2027, but you're gonna find that first vulnerability report a lot easier to do if you've already got this stuff in place, starting today. Let's go to the next slide. So what do you need to so the that last slide was what tools do you need? This slide is what what outputs are those tools going to help you build. Right? So prioritized exposure register is sort of what it sounds like. It's prioritized exposure. Which things have the most vulnerabilities in the past? How do you know what's gonna happen in the future? Confirmed owners and mitigation actions, So, again, it's that mapping thing. You need to know what you're shipping and who owns every piece that you're shipping. The days where you could say, like, we'll figure it out from the org chart once we get the vulnerability really should be over. Again, that's not written strictly into the law. That's just a matter of what is it that you need to be ready to do when the time comes. Reportability decisions, supporting information, the same kind of thing. You need to have an owner in your organization of who decides what the, what vulnerability level it is. There was a question in chat that essentially was, Hey, exactly which things do we need to report? And for those of you with experience in vulnerability reporting, you know that some of these things are judgment calls as to exactly how severe it is. You need to have somebody identified in your organization who makes that final call. Is this severe enough to require a report? Given that that is now a legal obligation, that used to be something that, like, your CSO would do. Given that there's now a legal obligation, your lawyer is probably gonna be involved, as well. And they need to know ahead of time, they need to know by September 11 who's gonna make that decision if a vulnerability comes up on September 12? What kind of processes and procedures are they gonna put in place? A lot of these, for those of you in sophisticated companies, are already in place. And what you need to do is layer in whatever checklist you have for an incident needs to start including, maybe in fact, that's really what slide zero should have been. In your checklist for vulnerability, add, do the CRA stuff. Right? And that's really what this is the fine tuned detail of. Let's go to the next slide. So triage and mitigate. Again, this is one where most of you at sophisticated companies will already have a lot of this kind of stuff in place. And what you need to do is check it against, especially once the single reporting platform is out and we know exactly I admit, little frustrating to prepare this talk because ideally, we would love to give you screenshots of here's the form you're gonna have to fill out. We don't have those screenshots yet. So, a little hard to tell you exactly what you're gonna have to fill out. But especially once the site goes up, you and your team are going to want to sit there and say, what exactly are the fields that are gonna be needed? How do those map to our existing processes? And how do we, know that we're gonna have that information ready to plop into the form that we need to report. There's also gonna be I keep saying form, but by the but there will be an API for those of you who are companies that have, a higher volume of vulnerabilities. Yeah. I think that's I think that's good for yours since I'm already behind time because I'm already talking too much about this. So let's go to the next slide. So triage and I think maybe one of the final steps here, before we start going into the next step is that, of course, you have all heard this before from your CISOs, from everybody involved with with security. The best thing to do about vulnerabilities is to, have the vulnerabilities not happen. Right? So we've talked a lot here about understanding your code base, knowing what your exposure is so that if there is an exploit or vulnerability, you know, what is it that you need to do? That's gonna include, understanding what has real product exposure and how are you gonna prioritize it. Right? And that me and then critical you can't see me pointing here while you can see my fingers, but contain or remediate them. Right? And that's what we're gonna go into next is what are the things you need to do to make sure that you are, ideally, you never want to have to use this process. Right? And that's, again, where this goal of what are the things that are become hard requirements in 2027 are soft requirements in nine days because you really want to do them well. Let's go to the next slide. So the last slide in this section, I think. Yeah. You wanna know. These are all things you should have. A prioritized mitigation plan. Like I said, many of you will already have that checklist. You need to just add CRA stuff into it. So let's just go ahead and skip then to the next slide. Prevention first strategy for all new code. For those of you who have spent a little bit of time with the CRA, you might be familiar with the phrase secure by design. The big goal of the CRA is that they would like the software industry to shift security left instead of, dealing with you know, it's not pretending the vulnerabilities will go away. We will always have vulnerabilities. But they want us to, instead of being reactive as an industry and we deal with vulnerabilities as they happen, they want us to shift left and deal as much as possible at the design phase with how do we prevent bugs from happening. And so this stuff is stuff this next section in the deck, this prevention first strategy, this is stuff that you if you are not already doing it, you want to start doing it now. Use September 11 as a way to raise awareness. It is not required that by September 11, you implement a prevention first strategy. That is going to be required in 2027. But for this year, 09/11/2026, this is not required. Instead, think of this as an opportunity to raise awareness. When your CEO comes to you and says, I've heard about this CRA thing on LinkedIn. What do I need to know? The answer is, hey. September 11, we're gonna have to understand our code base so that when a vulnerability happens, we can report it appropriately. But by 2027, we're gonna have to have a prevention first strategy, a secure by design strategy for all new code. And mister CEO, missus CEO, we need to start thinking about that right now. So, so what is it you need to be doing? You need to define a standard. How is it that you are going to be doing this secure by default? What are your coding rules? You need to be verifying every change. You know, how are you knowing that every change you make does not regress you on a security perspective? Google has a great, report from Android that basically says the best way to keep code secure is to not write any new code. You only want to fix old code and write new code, in their case, in Rust. You wanna enforce these changes before merge. The good news is this a lot of this stuff sounds daunting and used to be daunting, and now there's a lot of tooling for it as we'll discuss later in the deck. You need to keep your controls and you need to not regress. Let's go to the next slide. You know, I I do see a question of the what will be for old code for vulnerabilities? You still need to know the mapping and things, that we've discussed apply to all of your code. Right? If you are still shipping it to your customers, then you need to, and I forget the exact standard. Maybe it's if you've shipped it in the last five years, Ekaterina. Maybe yeah. If you've shipped it in the last five years, you need to be able to go back and do this if a vulnerability is discovered in that old code. So all that that first section very much applies to old code. For new code, the key thing or for new code that intersects with old code, mostly you just don't wanna regress it. But we'll talk about what's that secure by design for new code. And by the way, I don't know I think there's sort of a more meta question embedded in that one, which is what's your obligation to go back and fix old code with Secure by Design? I think that's a little undefined, but suffice to say, I think that, the European Union and the regulatory agencies starting in 2027 are going to start asking what have you done to, improve the quality of that old code, either by, for example, wrapping some kind of new security layer around it, or by doing some of the things that we talk about here. Right? So this mentions, so this this slide is prevention first strategy for new code. You wanna prevent new vulnerabilities from entering new code. But a lot of the tactics described here also apply to old code. Right? So, for example, this talks about, fuzz testing or, secret scanning. You can still do those on old code. Right? Secrets can still be embedded in old code. Fuzz testing can still be applied to old code. And, you know, merge controls and release gates, one thing you can do is ensure that the old code stays old code. You don't want people like, oh, yeah. I'll just apply this patch to the old branch and accidentally creating a vulnerability that way. So you still need to have controls over your old code. What are other kinds of things that you can think of to do this prevention for strategy? Threat modeling, secure coding standards, analyzing every pull request. These kinds of things are best practices. And maybe if there's one sentence I can use to summarize CRA, it's making best practices common practices. Right? So these are the things you may have heard about from other CISOs that you've seen on slide decks, but, oh, we've never had time to implement it at at my place. Now you need to make the time. When you have that conversation with your CEO, you say, hey. All this stuff that I really wanted to do, now is the time I need to be resourced to do it. Let's go to the next slide while I have my key. And, Victor, thank you for summarizing, my somewhat verbose answers in a concise form in the chat. Much appreciated. So secure by default verification. I think this is a little, very much the same thing, different words as the last one. What is it that you are trying to make sure that you have the outputs of? You need to be able to say, and you're eventually gonna wanna say this to your auditors as well. Here's our secure development baseline. Here's what we're doing with every single change, with every single merge, with every single release to make sure we haven't regressed, to make sure we still know when we've added a dependency, did that automatically get added to the s bomb? Because one of those things that tends to happen these days is, we update the SBOM every quarter or we update the SBOM right before release. No. You should be updating the SBOM on every single commit because if you're not updating the SBOM on every single commit, then you've got a gap between, your knowledge of the product and your analysis of the product and the constantly updating world that your developer's living in. Ruben, ended the product using this component four years ago. The, that's a great question, and it was one of the tricky edge cases. Ekaterina, correct me if I'm wrong because the timeline questions are a little tricky here. If you it's not active, right. If it's not. act yeah. The one thing that is, I think, somewhat for new products released after, 2027, you do have to be ready to support it for five years. And that. doesn't man the the mandatory timeline for new. products. For if there is, if there is a version you have released four years ago, but it's unsupported and it's not on the market anymore, it's all good if it's not available for purchase. Right. And that does include, by the way, some I would say some how to put it, support for five years does include releasing new versions that are essentially similar in functionality and essentially similar in price. Right? So if you release a new version and you're charging 10 times as much for it, you can't say, oh, the old the one point o is still supported. You do have to continue supporting that one point o for the five years, we believe. I mean, this is one of these things that there will be interpretations. And, for those, I don't know the mix of Americans and Europeans on the call. But a big, difference between American and European regulation like this one is that American regulators like to give you as much certainty as possible upfront. And European regulators are like, oh, yeah. We'll get to certainty and clarity eventually. We will all learn together. And in their mind and I I I think there's a lot to recommend about this position. Hey. We're gonna learn by doing. And so we can't give you clarity upfront. We're gonna iterate. And, when you put it that way, it sounds very software development. We're gonna learn by doing. We're gonna iterate. But, of course, you know, our companies, our CEOs, our CISOs want to know a a yes or no kinda answer, and European regulators don't really like giving that, which can be very frustrating to everybody, not just Americans. Yes. Substantial modification is the is the magic word I was looking for. Thank you, Alessandro. For those, in case it wasn't obvious from this, I am in California, and so this is, quite early for me. So certain magic words may not always come straight to the tongue. Let's go to the next slide. So this is a great slide. Quick readiness assessment. And, again, this sort of blends together a little bit. What do you need to do in nine days and what are the kinds of things you are going to need to be ready for in 2027? But, again, this is both a a little bit of a scary moment. As Tom said at the very beginning, do you need to panic? No. If your CEO panics a little bit and gives you some more resources so that, you have to deal with it in '20 so that you can be ready to deal with 2027, You know, the I as a good lawyer, I I aim to never ever panic my CEO. However, if I make my CEO aware that there are going to be challenges in 2027 that we need to resource now to deal with, I think that's an appropriate part of my job. So what are these questions that we need to be asking? One, are secure defaults encoded in the code base? This is again where we got back to what are your controls? What are the things that you know you have done the most to minimize your attack surface? And that that involves understanding your code base, etcetera. Two, are are changes to security critical code and configuration identified, reviewed and tested? Again, a great question here. Tracking what your changes, I would almost say to that all code in some sense is security critical. One of the things that CRA teaches us, is that we are responsible for the whole products that we're shipping, not just, oh, is it security critical? Right? It's not just this doesn't just apply to, the things that we have tended to historically worry about. For those of you who who do have a computer science degree, my computer science degree, we had a a safety course that talked about medical devices and cars and things like that. No. No. No. Because of how embedded security is into our whole society, all code to some extent is security critical code. So you need to think very broadly about this. Three, can every release be reproduced from this exact source build build inputs and dependencies? You're gonna have to be able to rebuild and fix your releases, so you need to be able to reproduce them. Must every code change pass security checks before it can merge? Again, this is one of these things you should have been doing before you absolutely need to be doing next year. September 11 is a good time for you to be asking that question and saying, hey, can we do this now? Similarly, build a release block to a serious security finding remains. What automated tooling do you have in place now that says, hey. We've got an open source component with a serious security vulnerability in it. Because part of the reason why we haven't mentioned this, but part of the reason why reporting is mandatory now is because listening to those reports becomes mandatory in 2027. And so this is exactly the kind of thing you need to be doing now to prepare for later. Do automated tests, exercise security critical code. Again, probably should have already been doing this. Now is your moment, your opportunity to gain, visibility into that problem. And to release tests to verify the security behavior, same. Let's go to the next one. And I think that's the end of my section. So Thank you, Luis. And, yes. That's the current that's the current standing. That's the seven questions you ask. And, essentially, I wanted to just give a free follow-up because nowadays, there are many, many reasons for why the procedure is needed. And, essentially, if you were, if you had to answer, your CEO or your CTO, why do we have the procedure and you need justification, you don't need a justification anymore. The European Union has it for you. So, how to plan for the future based on what's coming on the September 11? There are seven foundations for CRA readiness, not just for the vulnerability reporting readiness, but for the overall readiness. It's the secure body for development, consistent security controls, vulnerability identification and remediation, components transparency, code level evidence and reporting inputs. And, there are six main, and the seventh, if you are mature in your AI adoption journey, covering the AI coding workflows is a must for, make to make sure that your code base is ready for cyber resilience type. Out of those six plus one, well, I won't call them seven because it's six plus one, essentially, three are covered by what's coming on the September 11. However, as Luis just walked you through, to make sure that vulnerability identification, remediation, and component transparency are on point and ready for, the overall, kickoff of the reporting, there will be need there will be a need to establish components of secure by default development. There will be needs to establish components of consistent security controls. There will be a need to have code level evidence and reporting inputs because without those, essentially, it's going to be a very complicated journey to actually identify and remediate vulnerabilities and prevent them from happening in the future. Because as as we, saw in the beginning of the presentation, reporting timelines are kinda tight. So So it's twenty four hours after not there is an important distinction here. It's not after vulnerability has occurred, but after the organization has been made aware of it. So, for example, if the CVE is produced, doesn't mean that you have to run a report for it as from the moment that you have been made aware of it. So, essentially, it is still very it's still a very tight timeline, but a bit, kind of depending on your own awareness. However, if you fail to act on it on time, there may be liability coming with it. So, timelines are very, very strict, and it's something that a lot of organizations are not thinking about very thoroughly because, especially, if you're not used to be under regulatory scrutiny, if you, for example, are building something that was available in retail market and wasn't as, as regulated before CRA, it may be a significant change of pace, but, unfortunately, it is what it is. At least it's 2026, and we don't need to call them anymore because I used to work in pharmaceuticals and in pharmaceuticals. If there is an adverse event, at some point, you had to call them within these twenty four hours to make sure that they have actually, registered the, adverse event report via over the phone. And, obviously, phone lines are not available twenty four seven. So that was a fun, you know, fun time to be, working. Luckily, this this time, it's a bit easier even though the platform is still not operational, unfortunately. So, three points are covered. Three points plus one are left, and we will take a quick look at what actually can be done within Sonar and put the Sonar products suite to make sure that you are ready and you're ready to be set up. And, the forward looking strategy for this one for these four, is to define standards and approach configuration defaults and enforce automated application of set standards. Regardless of the tool, with Sonar or not, this is kind of like the must, especially if you are working in a business that has the AI augmented, sort of development life cycle. Given the amount of code that you are shipping, it it's not sustainable anymore to manually review it. It has to be automated. Standard, enforcement has to be automated or accelerated in a way because, otherwise, you will be falling behind, unfortunately. And because, obviously, AI is not just accelerating us as defenders, it's also accelerating attackers. So the probability of the exploit is unfortunately growing very high. Then the consistent security controls, It doesn't just need to be automated. It needs to be shared across the organization because, as Luis said, when we were talking about just mapping the code base because, you may have, I don't know, groups of people who know what what they have in their own code. However, you need to have the unified view of the code base as an asset for the organization because not the employees, but the organization is liable for what's contained in your code. And this is why controls has to be consistent and manageable and, transparent in a way. Code level evidence reporting inputs has to be capturing the, review and verification results, control outcomes, changes, and remediation activity. So for you, if there is an incident, there is an exploit, it's not a we have twenty four hours, and we're, like, trying to scrape from like, squeeze it out of everyone. It's just there. If there's an issue, you'll be able to trust it and say, yeah. This is where it happened. This is how it's going to be mitigated. And for governed the encoding workflows, obviously, it has to be the same. As for humans, because CRA or nor any other regulation, it doesn't make any difference between who has contributed to the code base. AR and human does pretty care. It has to be the same for all. Okay. What's what can be done with Sonar? Secure by default development. It's, as you can see here in the bottom, there is the full list of the products that can be implemented within the your SOAR IQ workflow. Doesn't have to be all of that, but I would say that for the, meaningful coverage of the cyber security requirements, SoroCube and SoroCube advanced security are a must. It's kind of like the baseline or, secure by default development that's powered by SoroCube. Good news here is that it's the single workflow. It's the single workflow that covers pretty significant chunk of requirements that CyberZiones Act has for code bases, and it's covered by a single product that's very well integrated into, with, like, for example, Jira. So it can be shipped into majorly, I wouldn't say any, but a lot of different operational segments that you may have. So secure by default development, you get to define approving, define the standards, and apply them, configure rules for null vulnerability secrets, infrastructure, scope, reliability, and maintainability, give developers early feedback, through ID and pull request analysis, then set quality gates and release conditions for new change code, enforce gate results to report the current CICD merge policies, and remediate failures and reanalyze changes before release. This is like a very quick overview. It's it goes much deeper. My colleagues have shared the link to this CRA solution page, in the chat. You can dive deeper, you can request a demo, because we do have a very significant coverage work what survey has required. Consistent security controls, as I said, something that can be applied throughout your entire organization to multiple teams, multiple structures, however you want it. It may be like a company or a group of companies. We support multiple operational setups, and, it's very flexible. It can be applied quality fast quality gates can be applied across in scope teams and code bases within StoryCube. And, also, it can be said to be as strict as you need them to be. So, for example, we know that's why Verizon is obviously very strict on security. However, requirements for reliability and maintainability may be a bit less strict, so it can be reflected in your quality gate setup or a release control setup. So you don't have to spend time on not priority issue remediation, and you will be able to first deal with the security issue that will fail your, pull request and then move to, less of the priority issues. And I will actually show you how to what what do we have in scope to help you triage things. Then you get to synchronize local feedback, PR checks, and CICD uniform as with central standards. And we need for adoption and configuration across projects, application, and portfolios. We have multiple levels of, overview and reporting. Portfolios is the highest one. Then there's applications and projects. So to make sure that you are able to trace, either on the organization level or, like, kind of, like, individual team levels or in individual project levels if there's a need be, for you to, again, to be able to simplify, the workflow and control over the adoption. Because with compliance, however good it is, Solr is the incredible solution that works within your development workflow, human be it human or an agent. We don't really care, if you're honest. Adoption is very important because without adoption, there will be gaps, and gaps in compliance are usually very expensive. Vulnerability identification. So what do we have is that we have SaaS, state analysis, we have sequence detection, and decomposition analysis to identify risk in proprietary code and components. We're working on reachability analysis, and we we have recently released Hunter Agent to uncover risk requiring deeper application context, which is incredible. Hunter Agent actually has, significantly, increased the coverage for, this, CRA requirements within the summary cube. There will be a blog post coming, blog post about it coming out very soon. So you'll keep following our website. And then you get to validate, classify, and track findings through continuous analysis and use it as evidence where there is a need to see what, how the remediation has been approached to. Component transparency. Again, you get to analyze project manifest log files, build information, all of that, for vulnerabilities, use reachability to assess relevance and generate response and fax information, and keep component data current through recurring analysis. There's a caveat there. We do not retain, SBOMS for as long as you would probably like them, so you will need to export them. But export, SBOM export means for IQ takes seconds or sometimes minutes for push projects, but it's very it's a very quick and efficient process. So you can export it at any PR or at any release or whatever your procedure requires and keep it for your records as a part of the broader evidence package. We do provide you with that. Vulnerability remediation. Here, we'd like to mention that we have recently acquired Guitar, which is an amazingly code for your company that helps to, simplify and streamline remediation, especially when it comes to the new code. So vulnerability remediation in the prevention form, will be to Guitar, and we also have a mediation agent that will help you to deal with the legacy code and tactile vulnerabilities in that. You get to prioritize finding using severity, reachability, code context, and policy. Remediate issues through developer guidance from mediation agent or guitar, with mediation agent in back file, guitar, NPR, if it's a new code, and reanalyze every proposed fix and track its resolution before merge or release. CodeLab evidence and reporting input. As I mentioned, we have multiple, ways of multiple levels of reporting. We have security reports. We are starting to roll out compliance reports now. You will be able to see the, there is a dedicated report for subBrazilian attack that I will show you in a second. There is the results of the analysis by the system, qualitative outcomes, issue decisions, remediation history, and audit logs. Everything that can be exported, everything is a part of your evidence package. And depending on where you are and how your, auditing process is set, since we we don't bill you by SIP, so you can create an account for auditors if there's a need. If you, for example, if you have frequent audits, sometimes a company I used to work for, we did have, like, an account for the auditor that can just go into, solution with unfortunately, we didn't have SonarQube, but a solution like SonarQube to check and see. And in SonarQube, you can do it easily because, again, we don't bill you per se. So So you can create as many auditor accounts as you want and give them access to dashboards and reports to be able to, assess the status of the code base. You can also also export security reports in multiple formats. Same goes to s b o m and v x. And you guide to export as a part of either CRA evidence reporting packages because, as you probably know, CRA is unfortunately not just about the code basis, but about infrastructure and all that comes with it, hardware, and many, many other, interesting things. And last but not least is the current AI coding workflows. Our recent, release is this on our vortex that, gives agents approved context and constraints and also allows to analyze code during generation. It gives a the agent feedback if an issue has been detected, and the issue is fixed pre PR, pre quality gate. So you will get, significantly less findings at the quality gate step, which will help to lighten the reviewer load, lighten the, human load that has to kind of, like, sign the final insurance for it. You get to ensure AI code assurance by applying same controls and standards to AI as human generated changes because, as I said, CRA doesn't really care who created the code. You are responsible for all of it. And, frankly, we do not care either. As long as it's code, we will be able to help you verify it. And you get to use guitar and or remediation agent to correct issues, with server queue verifying proposed fixes before merge to make sure that it flows as kind of, like, as they not just you got all of this alert and now we have to deal with it. We can help you automate the the the dealing with it part as well. And the CRA report, is our recent release, which is very, exciting for multiple reasons. But one of my favorite ways to think about it is that with CRA report, you actually get a very useful triage tool because it's mapped against the requirements of index one. And if you, after the setup of summary cube, you're kind of like, okay. What do I need to start looking at? I have hundreds of issues. I have hundreds of dependency risks. You can go to the CR wave report and see, okay. So those issues are mapped against the certain requirements, and this is where it can begin. And then going on the level of the issue, you can prioritize them by severity, for example, and just start there. It is a very useful patch tool, I would say, and also a very useful feasibility tool, towards Annex one requirements within your code base. So, nine days is a interesting timeline, and I'm very happy you are here and not in panic, because the good news is that basic deployment of SonoCube and SonoCube advanced security, it takes around forty hours. I have verified this number with solution engineers, but they told me to tell you that it depends on the multitude of components, but it should be able to get up in under around forty eight hours. But please do not be do not let procurement, be your biggest time either here. Get in touch with ourselves to invite us for the webinar. And, within the onboarding process, you will be able to walk through all of these steps kind of, like, during the, onboarding, especially if, this presentation we support. You will be able to kind of, like, fine tune, the setup for because, again, it's a developer friendly solution that's been developed by people with a lot of expertise in how to make sure that the workflow is as useful as possible. You will be able to get it up pretty very quickly and to make sure that it works. Nine days. Yeah. I'm it's it's it's a very short time line, but it is enough to make meaningful progress towards the already readiness with SORIQ. And after those nine days have passed, after we are waking up in September 12, it will be time to get ready for the full survey applications to begin in 2027 because there will be so much more coming. And, this is, I would say, is a very it's a very good trial run to the full vacations kicking in in a year. But still, given the all of this scrutiny that comes around AI when it comes to cybersecurity and cybersecurity issues, I assume that there will be a lot of attention, to CRI and how it works and how it kind of, like, bases out. So the time is now. If you're here, you're in a good place because the time is now, and, it is going to, unfortunately, become a bit too late too soon. Okay. We're we'll have two more webinars in September, so please register for the upcoming webinars. You can follow the links on the screen if you check the QR codes. And, I won't go to the q and a slide, but we will roll out the q and a because we can do two things in parallel and answer questions and check the webinars on the same time. Okay. Cool. Thank you, Katrina and Louis. That was amazing. So much to, a complex topic. Right? I had, I had no idea. And, and thanks to Victor for, answering. I think you've done answered pretty much all of the questions. We have loads of questions, so thank you for all the questions. There's obviously you know, it's a complex topic. There's lots of interest. That's great to hear. Hopefully, we've answered all of those. One thing that didn't come up is, I mean, but either to Ekaterina or Lewis, do you expect this regulation to change, expand because of AI? Obviously, like, things are happening so much faster now. Is it was this a regulation built for AI speed vulnerabilities? It definitely was not built for AI speed, but with I I would say it's a very rare case, at least from my point of view. I know Luis, because of his attached to open source, has a very different point of view for this. But from my point of view, it's a kind of like, it's a blessing in disguise kind of thing because given that it is now coming out, it's a very good time to be security aware and kind of, like, cybersecurity conscious, and it is kind of like a very good slap on the wrist for all of us as developers to say, like, hey. We need to act now because it may be too late soon when AI is empowering every other attacker that has enough spy to and and and enough money to power. So, yeah, I I think it is, it was not definitely developed in with AI in mind, but it just happened very timely. I mean, I yeah. I think I would add that the, the the there there are levels of specificity. Right? So, like, the law itself is actually pretty vague and sort of says you gotta be secure. And, like, and that, it turns out, it that is still totally 100% applicable. Right? Yeah. You know, and and I should say, actually, because I think it's an important and a common and I just fell into it myself. Right? Common misunderstanding. It doesn't actually say you have to be secure. Right? It says you have to try to build in a secure manner because it knows that there's no such thing as perfectly the only perfectly secure computer is a computer that's turned off. Right? And and and they they knew that when they wrote this. So the, so the the thinking behind it is you have to do your best to make it secure. By the way, there's gonna be all these regulate there's gonna be all these specific details that they delegated that are gonna tell you this is more or less what best practices are, that you should follow these. But those are gonna get updated for AI. And in the meantime, if you are doing if you are either ignoring AI or using AI I mean, I think the other important thing here is that a lot of this stuff that needs to be done is, like, boring, miserable stuff that's not fun. Right? It's like you should really be doing a lot more test driven development. You should really be doing a lot more active probing of vulnerabilities. Well, like, guess what? Like, we now have tools for that Yeah. that like that we didn't have a year ago, right? Like, we've got things like, hunter agents and you can just ask the machine This this code has no tests. It should have a lot of tests. Go write a lot of tests. Right? And those tests won't be perfect, but they will be a lot better than zero. And so I think that cuts both ways. Right? It it will actually not in all dimensions, but in some dimensions, it will help us comply with CRA in, like, a not just in a checking the box kind of way, but in a genuine building better processes kind of way. Because part of the reason these things are best practices and not standard practices is because some of them are not a lot of fun for developers to do. And so we can now delegate those to the machine and get decent results a lot of cases. Yeah. So, really, this makes it more urgent anyway, you know, to have this have these levels, but also more achievable, hopefully. So so maybe it is a good time. Maybe a bit earlier. I could have done well as well. Cool. Alright. I don't know if there's any other questions that you guys have seen that we've received that you think could do with a bit more, out outlying. There's been a lot. I think Victor's done a fantastic job of answering them. There were some questions about, cube, SonoCube server and cloud, and I think we're pretty close on these to parity, if if not now, Yep. in the the the LTA release that we've got coming later this month, which brings brings the two really up to parity. So lots of the new features that you've seen on cloud will be available in that release of server coming up. So so, hopefully, those those kind of complications are gone. But, obviously, the addition stuff is still is still a kind of constraint. So yeah. Yeah. Cool. Alright. I think we're almost up on time. We should probably finish. I think we'll get cut off on the hour. Is there anything else you guys would like to finish on? I mean, I would just say that my one sentence, you know, summary of all this is, don't panic. This is helping you create energy and motivation within your organization to do something that to do things that really should have been being done already. Right? It is not is not asking you to do new impossible things. It's asking you to to bring again to make best practices standard practices. It's not impossible practices, standard practices. It's doing the kinds of things we should already been doing, including, you know, using a lot of this, sonar q sonar provided stack. Any one sentence summary from you, Katarina? I would probably, I will probably, yes, support what you just said. It is about making the compliance is a very good operational strategy if you think about it from the security point of view. They do care everything, compliance cares about in soft and blunt life cycle is security. And it's a good thing because you don't have to jump through hoops about the, naming conventions or something very interesting. It's just just make make reasonable decisions and take reasonable action. That's it, really. Cool. Amazing. Okay. Well, thank you so much, everybody, and thank you for all the questions for the people that have joined. We've had a lot of joiners, loads of great questions. If we haven't answered your question or you'd want to go into more depth, the Sonosource community is a great place to do that if you don't know it already. You'll get the developers answering your questions and all sorts of people, which is amazing. I think there's a there is a survey. So thank you for completing the survey. If you're able to, that'll be fantastic. And, I think that is us. So, so, yeah, thank you very much. We'll see you again next time. We've got two more, very relevant, webinars coming up soon, so please join us with those. And, we'll see you again soon. Thank you very much. you. Thank you.